Form validation happens when the data is cleaned. If you want to customize\nthis process, there are various places to make changes, each one serving a\ndifferent purpose. Three types of cleaning methods are run during form\nprocessing. These are normally executed when you call the is_valid()\nmethod on a form. There are other things that can also trigger cleaning and\nvalidation (accessing the errors attribute or calling full_clean()\ndirectly), but normally they won't be needed.
In general, any cleaning method can raise ValidationError if there is a\nproblem with the data it is processing, passing the relevant information to\nthe ValidationError constructor. See below\nfor the best practice in raising ValidationError. If no ValidationError\nis raised, the method should return the cleaned (normalized) data as a Python\nobject.
Most validation can be done using validators - simple helpers that can be\nreused easily. Validators are simple functions (or callables) that take a single\nargument and raise ValidationError on invalid input. Validators are run\nafter the field's to_python and validate methods have been called.
Validation of a form is split into several steps, which can be customized or\noverridden:
\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.
The clean_<fieldname>() method is called on a form subclass -- where\n<fieldname> is replaced with the name of the form field attribute.\nThis method does any cleaning that is specific to that particular\nattribute, unrelated to the type of field that it is. This method is not\npassed any parameters. You will need to look up the value of the field\nin self.cleaned_data and remember that it will be a Python object\nat this point, not the original string submitted in the form (it will be\nin cleaned_data because the general field clean() method, above,\nhas already cleaned the data once).
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 just a CharField), but you want a\nformfield-specific piece of validation and, possibly,\ncleaning/normalizing the 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.
Examples of each of these methods are provided below.
\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.
ValidationError を発生させるLink to this heading#エラーメッセージを柔軟かつ簡単にオーバーライドできるようにするため、以下のガイドラインを検討してください:
\n説明のための code をコンストラクタに渡します:
# Good\nValidationError(_('Invalid value'), code='invalid')\n\n# Bad\nValidationError(_('Invalid value'))\nメッセージには変数を強制しません; プレースホルダとコンストラクタの params 引数を使用します:
# Good\nValidationError(\n _('Invalid value: %(value)s'),\n params={'value': '42'},\n)\n\n# Bad\nValidationError(_('Invalid value: %s') % value)\n位置指定ではなく、マッピングキーを使います。
\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)\nメッセージを gettext でラップし、翻訳できるようにします:
# Good\nValidationError(_('Invalid value'))\n\n# Bad\nValidationError('Invalid value')\n全てを一緒に記述すると以下のようになります:
\nraise ValidationError(\n _('Invalid value: %(value)s'),\n code='invalid',\n params={'value': '42'},\n)\n再利用可能なフォーム、フォームフィールド、モデルフィールドを記述した場合、特にこのガイドラインの遵守が必要となります。
\n推奨はされませんが、バリデーションチェーンの最後で (例えばフォームの clean() メソッド) エラーメッセージのオーバーライドを 決してしない ことが確かな場合は、より簡潔に記述することもできます:
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).
If you detect multiple errors during a cleaning method and wish to signal all\nof them to the form submitter, it is possible to pass a list of errors to the\nValidationError constructor.
As above, it is recommended to pass a list of ValidationError instances\nwith codes and params but a list of strings will also work:
# Good\nraise ValidationError([\n ValidationError(_('Error 1'), code='error1'),\n ValidationError(_('Error 2'), code='error2'),\n])\n\n# Bad\nraise ValidationError([\n _('Error 1'),\n _('Error 2'),\n])\n前のセクションでは、フォームに対する検証が一般にどのように働くかを説明しました。実際の使われ方を見た方が機能をよく理解できるということが往々にしてあります。ここでは、説明した各機能を使った一連の小さな使用例を説明します。
\nDjango のフォーム (とモデル) フィールドは、バリデータと呼ばれるシンプルなユーティリティ関数とクラスの使用をサポートしています。バリデータは単純にカラブルオブジェクトか関数で、値を取って、値が有効な場合は何も返さず、無効な場合は exc:~django.core.exceptions.ValidationError を返します。フィールドの validators 引数を通してフィールドのコンストラクタに渡すことができます。もしくは、Field クラス自身で default_validators 属性を使って定義できます。
シンプルなバリデータはフィールドの内部で値を検証賞するために使用できます。Django の SlugField を見てみましょう:
from django.forms import CharField\nfrom django.core import validators\n\nclass SlugField(CharField):\n default_validators = [validators.validate_slug]\n見ての通り、SlugField はカスタマイズされたバリデータを伴う CharField で、このバリデータは送信されたテキストがいくつかの文字列ルールに従うかどうかを検証します。これはフィールド定義においても実装可能です:
slug = forms.SlugField()\nこれは以下と同じです:
\nslug = forms.CharField(validators=[validators.validate_slug])\n一般的なケース (例えば、E メールや正規表現に対する検証) は、Django が提供する既存のバリデータクラスを使って処理できます。例えば、validators.validate_slug は RegexValidator の第 1 引数をパターン ^[-a-zA-Z0-9_]+$ としたインスタンスです。バリデータを記述する のセクションを参照して、利用可能なバリデータのリストとバリデータの記述方法の例を確認できます。
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\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(MultiEmailField, self).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 simple ContactForm to demonstrate how you'd use this\nfield:
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)\nSimply use MultiEmailField like any other form field. When the\nis_valid() method is called on the form, the MultiEmailField.clean()\nmethod will be run as part of the cleaning process and it will, in turn, call\nthe custom to_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\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 forms.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\n\nclass ContactForm(forms.Form):\n # Everything as before.\n ...\n\n def clean(self):\n cleaned_data = super(ContactForm, self).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 forms.ValidationError(\n "Did not send for 'help' in the subject despite "\n "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.
\nThe call to super(ContactForm, self).clean() in the example code ensures\nthat any validation logic in parent classes is maintained. If your form\ninherits another that doesn't return a cleaned_data dictionary in its\nclean() method (doing so is optional), then don't assign cleaned_data\nto the result of the super() call and use self.cleaned_data instead:
def clean(self):\n super(ContactForm, self).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\nclass ContactForm(forms.Form):\n # Everything as before.\n ...\n\n def clean(self):\n cleaned_data = super(ContactForm, self).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 simple string, or preferably\nan instance of ValidationError. See ValidationError を発生させる for\nmore details. Note that add_error() automatically removes the field\nfrom cleaned_data.