# dokumentasi Django 2.2.9.dev20191202104323

# Pengesahan formulir dan bidang

Pengesahan formulir terjadi ketika data dibersihkan. Jika anda ingin menyesuaikan pengolahan ini, ada beragam tempat untuk membuat perubahan, setiap satu melayani tujuan berbeda. Tiga jenis dari metode membersihkan berjalan selama pengolahan formulir. Ini biasanya dijalankan ketika anda memanggil metode `is_valid()` pada sebuah formulir. Ada hal-hal lain yang dapat juga memicu membersihkan dan pengesahan (mengakses atribut `errors` atau memanggil `full_clean()` langsung), tetapi biasanya mereka tidak akan dibutuhkan.

Secara umum, metode pembersihan apapun dapat memunculkan `ValidationError` jika ada sebuah masalah dengan data itu sedang olah, melewatkan informasi bersangkut pautke pembangun `ValidationError`. See below untuk latihan terbaik dalam memunculkan `ValidationError`. Jika tidak `ValidationError` dimunculkan, metode harus mengembalikan data dibersihkan (dinormalkan) sebagai sebuah obyek Python.

Most validation can be done using validators - simple helpers that can be reused easily. Validators are simple functions (or callables) that take a single argument and raise `ValidationError` on invalid input. Validators are run after the field's `to_python` and `validate` methods have been called.

Pengesahan dari sebuah formulir dibagi menjadi beberapa langkah, yang dapat disesuaikan atau ditimpa:

- The `to_python()` method on a `Field` is the first step in every validation. It coerces the value to a correct datatype and raises `ValidationError` if that is not possible. This method accepts the raw value from the widget and returns the converted value. For example, a `FloatField` will turn the data into a Python `float` or raise a `ValidationError`.

- The `validate()` method on a `Field` handles field-specific validation that is not suitable for a validator. It takes a value that has been coerced to a correct datatype and raises `ValidationError` on any error. This method does not return anything and shouldn't alter the value. You should override it to handle validation logic that you can't or don't want to put in a validator.

- The `run_validators()` method on a `Field` runs all of the field's validators and aggregates all the errors into a single `ValidationError`. You shouldn't need to override this method.

- The `clean()` method on a `Field` subclass is responsible for running `to_python()`, `validate()`, and `run_validators()` in the correct order and propagating their errors. If, at any time, any of the methods raise `ValidationError`, the validation stops and that error is raised. This method returns the clean data, which is then inserted into the `cleaned_data` dictionary of the form.

- Metode clean_<fieldname>()` dipanggil di sebuah formulir subkelas -- dimana `<fieldname>` diganti dengan nama dari atribut bidang formulir. Metode ini melakukan pembersihan apapun yaitu khusus pada atribut tertentu, tidak terkait pada jenis dari bidang bahwa itu adalah. Metode ini tidak melewatkan parameter apapun. Anda akan butuh mencari nilai dari bidang di `self.cleaned_data` dan mengingat bahwa itu akan menjadi obyek Python pada titik ini, bukan string asli yang diajukan di formulir (itu akan di `cleaned_data` karena metode `clean()` bidang umum, diatas, telah membersihkan data sekali).

  For example, if you wanted to validate that the contents of a `CharField` called `serialnumber` was unique, `clean_serialnumber()` would be the right place to do this. You don't need a specific field (it's just a `CharField`), but you want a formfield-specific piece of validation and, possibly, cleaning/normalizing the data.

  The return value of this method replaces the existing value in `cleaned_data`, so it must be the field's value from `cleaned_data` (even if this method didn't change it) or a new cleaned value.

- The form subclass's `clean()` method can perform validation that requires access to multiple form fields. This is where you might put in checks such as "if field `A` is supplied, field `B` must contain a valid email address". This method can return a completely different dictionary if it wishes, which will be used as the `cleaned_data`.

  Since the field validation methods have been run by the time `clean()` is called, you also have access to the form's `errors` attribute which contains all the errors raised by cleaning of individual fields.

  Note that any errors raised by your `Form.clean()` override will not be associated with any field in particular. They go into a special "field" (called `__all__`), which you can access via the `non_field_errors()` method if you need to. If you want to attach errors to a specific field in the form, you need to call `add_error()`.

  Also note that there are special considerations when overriding the `clean()` method of a `ModelForm` subclass. (see the ModelForm documentation for more information)

These methods are run in the order given above, one field at a time. That is, for each field in the form (in the order they are declared in the form definition), the `Field.clean()` method (or its override) is run, then `clean_<fieldname>()`. Finally, once those two methods are run for every field, the `Form.clean()` method, or its override, is executed whether or not the previous methods have raised errors.

Contoh dari setiap cara ini disediakan dibawah.

As mentioned, any of these methods can raise a `ValidationError`. For any field, if the `Field.clean()` method raises a `ValidationError`, any field-specific cleaning method is not called. However, the cleaning methods for all remaining fields are still executed.

## Membangkitkan `ValidationError`

Untuk membuat pesan-pesan kesalahan lebih elastis dan mudah ditimpa, pertimbangkan panduan berikut ini:

- Sediakan gambaran `code` kesalahan pada pembangun:

      # Good
      ValidationError(_('Invalid value'), code='invalid')

      # Bad
      ValidationError(_('Invalid value'))

- Don't coerce variables into the message; use placeholders and the `params` argument of the constructor:

      # Good
      ValidationError(
          _('Invalid value: %(value)s'),
          params={'value': '42'},
      )

      # Bad
      ValidationError(_('Invalid value: %s') % value)

- Menggunakan kunci-kunci pemetaan daripada pembentukan penempatan. Ini mengadakan menaruh variabel dalam pesanan apapun atau menghilangkan mereka saam sekali ketika menulis kembali pesan:

      # Good
      ValidationError(
          _('Invalid value: %(value)s'),
          params={'value': '42'},
      )

      # Bad
      ValidationError(
          _('Invalid value: %s'),
          params=('42',),
      )

- Bungkus pesan dengan `gettext` untuk mengadakan terjemahan:

      # Good
      ValidationError(_('Invalid value'))

      # Bad
      ValidationError('Invalid value')

Menaruh semua bersama:

    raise ValidationError(
        _('Invalid value: %(value)s'),
        code='invalid',
        params={'value': '42'},
    )

Mengikuti panduan ini terutama jika anda menulis formulir digunakan kembali, bidang formulir, dan bidang model.

While not recommended, if you are at the end of the validation chain (i.e. your form `clean()` method) and you know you will never need to override your error message you can still opt for the less verbose:

    ValidationError(_('Invalid value: %s') % value)

The `Form.errors.as_data()` and `Form.errors.as_json()` methods greatly benefit from fully featured `ValidationError`s (with a `code` name and a `params` dictionary).

### Membangkitkan banyak kesalahan

Jika anda mengenali banyak kesalahan selama metode pembersihan dan berharap mensinyalkan semua dari mereka ke pengaju formulir, itu memungkinkan melewatkan daftar ke pembangun `ValidationError`.

Seperti diatas, itu dianjutkan melewatkan daftar dari instance `ValidationError` dengan `code` dan `params` tetapi sebuah daftar string juga akan bekerja:

    # Good
    raise ValidationError([
        ValidationError(_('Error 1'), code='error1'),
        ValidationError(_('Error 2'), code='error2'),
    ])

    # Bad
    raise ValidationError([
        _('Error 1'),
        _('Error 2'),
    ])

## Menggunakan pengesahan dalam praktik

The previous sections explained how validation works in general for forms. Since it can sometimes be easier to put things into place by seeing each feature in use, here are a series of small examples that use each of the previous features.

### Menggunakan pengesah

Django's form (and model) fields support use of simple utility functions and classes known as validators. A validator is merely a callable object or function that takes a value and simply returns nothing if the value is valid or raises a `ValidationError` if not. These can be passed to a field's constructor, via the field's `validators` argument, or defined on the `Field` class itself with the `default_validators` attribute.

Pengesah sederhana dapat digunakan untuk mensahkan nilai-nilai didalam bidang, mari kita melihat `SlugField` Django:

    from django.core import validators
    from django.forms import CharField

    class SlugField(CharField):
        default_validators = [validators.validate_slug]

Seperti anda dapat lihat, `SlugField` hanya sebuah `CharField` dengan pengesah disesuaikan yang mensahkan bahwa teks siajukan mematuhi beberapa peraturan karakter. Ini dapat juga diselesaikan pada pengertian bidang seperti:

    slug = forms.SlugField()

setara pada:

    slug = forms.CharField(validators=[validators.validate_slug])

Kasus-kasus umum seperti pengesahan terhadap sebuah surel atau sebuah regular expression dapat ditangani menggunakan kelas-kelas pengesah yang ada tersedia di Django. Sebagai contoh, `validators.validate_slug` adalah sebuah contoh dari `RegexValidator` dibangun dengan argumen pertama menjadi pola: `^[-a-zA-Z0-9_]+$`. Lihat bagian pada writing validators untuk melihat daftar dari apa yang tersedia dan untuk sebuah contoh dari bagaimana menulis sebuah pengesah.

### Pembersihan awalan bidang formulir

Let's first create a custom form field that validates its input is a string containing comma-separated email addresses. The full class looks like this:

    from django import forms
    from django.core.validators import validate_email

    class MultiEmailField(forms.Field):
        def to_python(self, value):
            """Normalize data to a list of strings."""
            # Return an empty list if no input was given.
            if not value:
                return []
            return value.split(',')

        def validate(self, value):
            """Check if value consists only of valid emails."""
            # Use the parent's handling of required fields, etc.
            super().validate(value)
            for email in value:
                validate_email(email)

Every form that uses this field will have these methods run before anything else can be done with the field's data. This is cleaning that is specific to this type of field, regardless of how it is subsequently used.

Mari kita membuat `ContactForm` sederhana untuk menunjukkan bagaimana anda akan menggunakan bidang ini:

    class ContactForm(forms.Form):
        subject = forms.CharField(max_length=100)
        message = forms.CharField()
        sender = forms.EmailField()
        recipients = MultiEmailField()
        cc_myself = forms.BooleanField(required=False)

Simply use `MultiEmailField` like any other form field. When the `is_valid()` method is called on the form, the `MultiEmailField.clean()` method will be run as part of the cleaning process and it will, in turn, call the custom `to_python()` and `validate()` methods.

### Membersihkan atribut bidang khusus

Continuing on from the previous example, suppose that in our `ContactForm`, we want to make sure that the `recipients` field always contains the address `"fred@example.com"`. This is validation that is specific to our form, so we don't want to put it into the general `MultiEmailField` class. Instead, we write a cleaning method that operates on the `recipients` field, like so:

    from django import forms

    class ContactForm(forms.Form):
        # Everything as before.
        ...

        def clean_recipients(self):
            data = self.cleaned_data['recipients']
            if "fred@example.com" not in data:
                raise forms.ValidationError("You have forgotten about Fred!")

            # Always return a value to use as the new cleaned data, even if
            # this method didn't change it.
            return data

### Membersihkan dan memeriksa bidang yang tergantung satu sama lain

Suppose we add another requirement to our contact form: if the `cc_myself` field is `True`, the `subject` must contain the word `"help"`. We are performing validation on more than one field at a time, so the form's `clean()` method is a good spot to do this. Notice that we are talking about the `clean()` method on the form here, whereas earlier we were writing a `clean()` method on a field. It's important to keep the field and form difference clear when working out where to validate things. Fields are single data points, forms are a collection of fields.

By the time the form's `clean()` method is called, all the individual field clean methods will have been run (the previous two sections), so `self.cleaned_data` will be populated with any data that has survived so far. So you also need to remember to allow for the fact that the fields you are wanting to validate might not have survived the initial individual field checks.

There are two ways to report any errors from this step. Probably the most common method is to display the error at the top of the form. To create such an error, you can raise a `ValidationError` from the `clean()` method. For example:

    from django import forms

    class ContactForm(forms.Form):
        # Everything as before.
        ...

        def clean(self):
            cleaned_data = super().clean()
            cc_myself = cleaned_data.get("cc_myself")
            subject = cleaned_data.get("subject")

            if cc_myself and subject:
                # Only do something if both fields are valid so far.
                if "help" not in subject:
                    raise forms.ValidationError(
                        "Did not send for 'help' in the subject despite "
                        "CC'ing yourself."
                    )

Dalam kode ini,jika kesalahan pengesahan dimunculkan, formulir akan menampilkan pesan kesalahan pada atas dari formulir (biasanya) menggambarkan masalah.

The call to `super().clean()` in the example code ensures that any validation logic in parent classes is maintained. If your form inherits another that doesn't return a `cleaned_data` dictionary in its `clean()` method (doing so is optional), then don't assign `cleaned_data` to the result of the `super()` call and use `self.cleaned_data` instead:

    def clean(self):
        super().clean()
        cc_myself = self.cleaned_data.get("cc_myself")
        ...

The second approach for reporting validation errors might involve assigning the error message to one of the fields. In this case, let's assign an error message to both the "subject" and "cc_myself" rows in the form display. Be careful when doing this in practice, since it can lead to confusing form output. We're showing what is possible here and leaving it up to you and your designers to work out what works effectively in your particular situation. Our new code (replacing the previous sample) looks like this:

    from django import forms

    class ContactForm(forms.Form):
        # Everything as before.
        ...

        def clean(self):
            cleaned_data = super().clean()
            cc_myself = cleaned_data.get("cc_myself")
            subject = cleaned_data.get("subject")

            if cc_myself and subject and "help" not in subject:
                msg = "Must put 'help' in subject when cc'ing yourself."
                self.add_error('cc_myself', msg)
                self.add_error('subject', msg)

The second argument of `add_error()` can be a simple string, or preferably an instance of `ValidationError`. See Membangkitkan ValidationError for more details. Note that `add_error()` automatically removes the field from `cleaned_data`.