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 - helpers that can be reused.\nValidators are functions (or callables) that take a single argument and raise\nValidationError on invalid input. Validators are run after the field's\nto_python and validate methods have been called.
Pengesahan dari sebuah formulir dibagi menjadi beberapa langkah, yang dapat disesuaikan atau ditimpa:
\nThe to_python() method on a Field is the first step in every\nvalidation. It coerces the value to a correct datatype and raises\nValidationError if that is not possible. This method accepts the raw\nvalue from the widget and returns the converted value. For example, a\nFloatField will turn the data into a Python float or raise a\nValidationError.
The validate() method on a Field handles field-specific validation\nthat is not suitable for a validator. It takes a value that has been\ncoerced to a correct datatype and raises ValidationError on any error.\nThis method does not return anything and shouldn't alter the value. You\nshould override it to handle validation logic that you can't or don't\nwant to put in a validator.
The run_validators() method on a Field runs all of the field's\nvalidators and aggregates all the errors into a single\nValidationError. You shouldn't need to override this method.
The clean() method on a Field subclass is responsible for running\nto_python(), validate(), and run_validators() in the correct\norder and propagating their errors. If, at any time, any of the methods\nraise ValidationError, the validation stops and that error is raised.\nThis method returns the clean data, which is then inserted into the\ncleaned_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\nCharField called serialnumber was unique,\nclean_serialnumber() would be the right place to do this. You don't\nneed a specific field (it's a CharField), but you want a\nformfield-specific piece of validation and, possibly, cleaning/normalizing\nthe data.
The return value of this method replaces the existing value in\ncleaned_data, so it must be the field's value from cleaned_data (even\nif this method didn't change it) or a new cleaned value.
The form subclass's clean() method can perform validation that requires\naccess to multiple form fields. This is where you might put in checks such as\n"if field A is supplied, field B must contain a valid email address".\nThis method can return a completely different dictionary if it wishes, which\nwill be used as the cleaned_data.
Since the field validation methods have been run by the time clean() is\ncalled, you also have access to the form's errors attribute which\ncontains all the errors raised by cleaning of individual fields.
Note that any errors raised by your Form.clean() override will not\nbe associated with any field in particular. They go into a special\n"field" (called __all__), which you can access via the\nnon_field_errors() method if you need to. If you\nwant to attach errors to a specific field in the form, you need to call\nadd_error().
Also note that there are special considerations when overriding\nthe clean() method of a ModelForm subclass. (see the\nModelForm documentation for more information)
These methods are run in the order given above, one field at a time. That is,\nfor each field in the form (in the order they are declared in the form\ndefinition), the Field.clean() method (or its override) is run, then\nclean_<fieldname>(). Finally, once those two methods are run for every\nfield, the Form.clean() method, or its override, is executed whether\nor not the previous methods have raised errors.
Contoh dari setiap cara ini disediakan dibawah.
\nAs mentioned, any of these methods can raise a ValidationError. For any\nfield, if the Field.clean() method raises a ValidationError, any\nfield-specific cleaning method is not called. However, the cleaning methods\nfor all remaining fields are still executed.
ValidationErrorLink to this heading#Untuk membuat pesan-pesan kesalahan lebih elastis dan mudah ditimpa, pertimbangkan panduan berikut ini:
\nSediakan gambaran code kesalahan pada pembangun:
# Good\nValidationError(_("Invalid value"), code="invalid")\n\n# Bad\nValidationError(_("Invalid value"))\nDon't coerce variables into the message; use placeholders and the params\nargument of the constructor:
# Good\nValidationError(\n _("Invalid value: %(value)s"),\n params={"value": "42"},\n)\n\n# Bad\nValidationError(_("Invalid value: %s") % value)\nMenggunakan kunci-kunci pemetaan daripada pembentukan penempatan. Ini mengadakan menaruh variabel dalam pesanan apapun atau menghilangkan mereka saam sekali ketika menulis kembali pesan:
\n# Good\nValidationError(\n _("Invalid value: %(value)s"),\n params={"value": "42"},\n)\n\n# Bad\nValidationError(\n _("Invalid value: %s"),\n params=("42",),\n)\nBungkus pesan dengan gettext untuk mengadakan terjemahan:
# Good\nValidationError(_("Invalid value"))\n\n# Bad\nValidationError("Invalid value")\nMenaruh semua bersama:
\nraise ValidationError(\n _("Invalid value: %(value)s"),\n code="invalid",\n params={"value": "42"},\n)\nMengikuti panduan ini terutama jika anda menulis formulir digunakan kembali, bidang formulir, dan bidang model.
\nWhile not recommended, if you are at the end of the validation chain\n(i.e. your form clean() method) and you know you will never need\nto override your error message you can still opt for the less verbose:
ValidationError(_("Invalid value: %s") % value)\nThe Form.errors.as_data() and\nForm.errors.as_json() methods\ngreatly benefit from fully featured ValidationErrors (with a code name\nand a params dictionary).
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\nraise ValidationError(\n [\n ValidationError(_("Error 1"), code="error1"),\n ValidationError(_("Error 2"), code="error2"),\n ]\n)\n\n# Bad\nraise ValidationError(\n [\n _("Error 1"),\n _("Error 2"),\n ]\n)\nThe previous sections explained how validation works in general for forms.\nSince it can sometimes be easier to put things into place by seeing each\nfeature in use, here are a series of small examples that use each of the\nprevious features.
\nDjango's form (and model) fields support use of utility functions and classes\nknown as validators. A validator is a callable object or function that takes a\nvalue and returns nothing if the value is valid or raises a\nValidationError if not. These can be passed to a\nfield's constructor, via the field's validators argument, or defined on the\nField class itself with the default_validators\nattribute.
Validators can be used to validate values inside the field, let's have a look\nat Django's SlugField:
from django.core import validators\nfrom django.forms import CharField\n\n\nclass SlugField(CharField):\n default_validators = [validators.validate_slug]\nAs you can see, SlugField is a CharField with a customized validator\nthat validates that submitted text obeys to some character rules. This can also\nbe done on field definition so:
slug = forms.SlugField()\nsetara pada:
\nslug = forms.CharField(validators=[validators.validate_slug])\nCommon cases such as validating against an email or a regular expression can be\nhandled using existing validator classes available in Django. For example,\nvalidators.validate_slug is an instance of\na RegexValidator constructed with the first\nargument being the pattern: ^[-a-zA-Z0-9_]+\\Z. See the section on\nwriting validators to see a list of what is already\navailable and for an example of how to write a validator.
Let's first create a custom form field that validates its input is a string\ncontaining comma-separated email addresses. The full class looks like this:
\nfrom django import forms\nfrom django.core.validators import validate_email\n\n\nclass MultiEmailField(forms.Field):\n def to_python(self, value):\n """Normalize data to a list of strings."""\n # Return an empty list if no input was given.\n if not value:\n return []\n return value.split(",")\n\n def validate(self, value):\n """Check if value consists only of valid emails."""\n # Use the parent's handling of required fields, etc.\n super().validate(value)\n for email in value:\n validate_email(email)\nEvery form that uses this field will have these methods run before anything\nelse can be done with the field's data. This is cleaning that is specific to\nthis type of field, regardless of how it is subsequently used.
\nLet's create a ContactForm to demonstrate how you'd use this field:
class ContactForm(forms.Form):\n subject = forms.CharField(max_length=100)\n message = forms.CharField()\n sender = forms.EmailField()\n recipients = MultiEmailField()\n cc_myself = forms.BooleanField(required=False)\nUse MultiEmailField like any other form field. When the is_valid()\nmethod is called on the form, the MultiEmailField.clean() method will be\nrun as part of the cleaning process and it will, in turn, call the custom\nto_python() and validate() methods.
Continuing on from the previous example, suppose that in our ContactForm,\nwe want to make sure that the recipients field always contains the address\n"fred@example.com". This is validation that is specific to our form, so we\ndon't want to put it into the general MultiEmailField class. Instead, we\nwrite a cleaning method that operates on the recipients field, like so:
from django import forms\nfrom django.core.exceptions import ValidationError\n\n\nclass ContactForm(forms.Form):\n # Everything as before.\n ...\n\n def clean_recipients(self):\n data = self.cleaned_data["recipients"]\n if "fred@example.com" not in data:\n raise ValidationError("You have forgotten about Fred!")\n\n # Always return a value to use as the new cleaned data, even if\n # this method didn't change it.\n return data\nSuppose we add another requirement to our contact form: if the cc_myself\nfield is True, the subject must contain the word "help". We are\nperforming validation on more than one field at a time, so the form's\nclean() method is a good spot to do this. Notice that we are\ntalking about the clean() method on the form here, whereas earlier we were\nwriting a clean() method on a field. It's important to keep the field and\nform difference clear when working out where to validate things. Fields are\nsingle data points, forms are a collection of fields.
By the time the form's clean() method is called, all the individual field\nclean methods will have been run (the previous two sections), so\nself.cleaned_data will be populated with any data that has survived so\nfar. So you also need to remember to allow for the fact that the fields you\nare wanting to validate might not have survived the initial individual field\nchecks.
There are two ways to report any errors from this step. Probably the most\ncommon method is to display the error at the top of the form. To create such\nan error, you can raise a ValidationError from the clean() method. For\nexample:
from django import forms\nfrom django.core.exceptions import ValidationError\n\n\nclass ContactForm(forms.Form):\n # Everything as before.\n ...\n\n def clean(self):\n cleaned_data = super().clean()\n cc_myself = cleaned_data.get("cc_myself")\n subject = cleaned_data.get("subject")\n\n if cc_myself and subject:\n # Only do something if both fields are valid so far.\n if "help" not in subject:\n raise ValidationError(\n "Did not send for 'help' in the subject despite CC'ing yourself."\n )\nIn this code, if the validation error is raised, the form will display an\nerror message at the top of the form (normally) describing the problem. Such\nerrors are non-field errors, which are displayed in the template with\n{{ form.non_field_errors }}.
The call to super().clean() in the example code ensures that any validation\nlogic in parent classes is maintained. If your form inherits another that\ndoesn't return a cleaned_data dictionary in its clean() method (doing\nso is optional), then don't assign cleaned_data to the result of the\nsuper() call and use self.cleaned_data instead:
def clean(self):\n super().clean()\n cc_myself = self.cleaned_data.get("cc_myself")\n ...\nThe second approach for reporting validation errors might involve assigning the\nerror message to one of the fields. In this case, let's assign an error message\nto both the "subject" and "cc_myself" rows in the form display. Be careful when\ndoing this in practice, since it can lead to confusing form output. We're\nshowing what is possible here and leaving it up to you and your designers to\nwork out what works effectively in your particular situation. Our new code\n(replacing the previous sample) looks like this:
\nfrom django import forms\n\n\nclass ContactForm(forms.Form):\n # Everything as before.\n ...\n\n def clean(self):\n cleaned_data = super().clean()\n cc_myself = cleaned_data.get("cc_myself")\n subject = cleaned_data.get("subject")\n\n if cc_myself and subject and "help" not in subject:\n msg = "Must put 'help' in subject when cc'ing yourself."\n self.add_error("cc_myself", msg)\n self.add_error("subject", msg)\nThe second argument of add_error() can be a string, or preferably an\ninstance of ValidationError. See Membangkitkan ValidationError for more\ndetails. Note that add_error() automatically removes the field from\ncleaned_data.