フォームとフィールドの検証¶
Form validation happens when the data is cleaned. If you want to customize
this process, there are various places to make changes, each one serving a
different purpose. Three types of cleaning methods are run during form
processing. These are normally executed when you call the is_valid()
method on a form. There are other things that can also trigger cleaning and
validation (accessing the errors
attribute or calling full_clean()
directly), but normally they won’t be needed.
In general, any cleaning method can raise ValidationError
if there is a
problem with the data it is processing, passing the relevant information to
the ValidationError
constructor. See below
for the best practice in raising ValidationError
. If no ValidationError
is raised, the method should return the cleaned (normalized) data as a Python
object.
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.
Validation of a form is split into several steps, which can be customized or overridden:
The
to_python()
method on aField
is the first step in every validation. It coerces the value to a correct datatype and raisesValidationError
if that is not possible. This method accepts the raw value from the widget and returns the converted value. For example, aFloatField
will turn the data into a Pythonfloat
or raise aValidationError
.The
validate()
method on aField
handles field-specific validation that is not suitable for a validator. It takes a value that has been coerced to a correct datatype and raisesValidationError
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 aField
runs all of the field’s validators and aggregates all the errors into a singleValidationError
. You shouldn’t need to override this method.The
clean()
method on aField
subclass is responsible for runningto_python()
,validate()
, andrun_validators()
in the correct order and propagating their errors. If, at any time, any of the methods raiseValidationError
, the validation stops and that error is raised. This method returns the clean data, which is then inserted into thecleaned_data
dictionary of the form.The
clean_<fieldname>()
method is called on a form subclass – where<fieldname>
is replaced with the name of the form field attribute. This method does any cleaning that is specific to that particular attribute, unrelated to the type of field that it is. This method is not passed any parameters. You will need to look up the value of the field inself.cleaned_data
and remember that it will be a Python object at this point, not the original string submitted in the form (it will be incleaned_data
because the general fieldclean()
method, above, has already cleaned the data once).For example, if you wanted to validate that the contents of a
CharField
calledserialnumber
was unique,clean_serialnumber()
would be the right place to do this. You don’t need a specific field (it’s just aCharField
), 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 fromcleaned_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 fieldA
is supplied, fieldB
must contain a valid email address」. This method can return a completely different dictionary if it wishes, which will be used as thecleaned_data
.Since the field validation methods have been run by the time
clean()
is called, you also have access to the form’serrors
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 thenon_field_errors()
method if you need to. If you want to attach errors to a specific field in the form, you need to calladd_error()
.Also note that there are special considerations when overriding the
clean()
method of aModelForm
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.
Examples of each of these methods are provided below.
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.
ValidationError
を発生させる¶
エラーメッセージを柔軟かつ簡単にオーバーライドできるようにするため、以下のガイドラインを検討してください:
説明のための
code
をコンストラクタに渡します:# Good ValidationError(_('Invalid value'), code='invalid') # Bad ValidationError(_('Invalid value'))
メッセージには変数を強制しません; プレースホルダとコンストラクタの
params
引数を使用します:# Good ValidationError( _('Invalid value: %(value)s'), params={'value': '42'}, ) # Bad ValidationError(_('Invalid value: %s') % value)
位置指定ではなく、マッピングキーを使います。
# Good ValidationError( _('Invalid value: %(value)s'), params={'value': '42'}, ) # Bad ValidationError( _('Invalid value: %s'), params=('42',), )
メッセージを
gettext
でラップし、翻訳できるようにします:# Good ValidationError(_('Invalid value')) # Bad ValidationError('Invalid value')
全てを一緒に記述すると以下のようになります:
raise ValidationError(
_('Invalid value: %(value)s'),
code='invalid',
params={'value': '42'},
)
再利用可能なフォーム、フォームフィールド、モデルフィールドを記述した場合、特にこのガイドラインの遵守が必要となります。
推奨はされませんが、バリデーションチェーンの最後で (例えばフォームの clean()
メソッド) エラーメッセージのオーバーライドを 決してしない ことが確かな場合は、より簡潔に記述することもできます:
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).
複数のエラーを起こす¶
If you detect multiple errors during a cleaning method and wish to signal all
of them to the form submitter, it is possible to pass a list of errors to the
ValidationError
constructor.
As above, it is recommended to pass a list of ValidationError
instances
with code
s and params
but a list of strings will also work:
# Good
raise ValidationError([
ValidationError(_('Error 1'), code='error1'),
ValidationError(_('Error 2'), code='error2'),
])
# Bad
raise ValidationError([
_('Error 1'),
_('Error 2'),
])
実際にバリデーションを使用する¶
前のセクションでは、フォームに対する検証が一般にどのように働くかを説明しました。実際の使われ方を見た方が機能をよく理解できるということが往々にしてあります。ここでは、説明した各機能を使った一連の小さな使用例を説明します。
バリデータを使う¶
Django のフォーム (とモデル) フィールドは、バリデータと呼ばれるシンプルなユーティリティ関数とクラスの使用をサポートしています。バリデータは単純にカラブルオブジェクトか関数で、値を取って、値が有効な場合は何も返さず、無効な場合は exc:~django.core.exceptions.ValidationError を返します。フィールドの validators
引数を通してフィールドのコンストラクタに渡すことができます。もしくは、Field
クラス自身で default_validators
属性を使って定義できます。
シンプルなバリデータはフィールドの内部で値を検証賞するために使用できます。Django の SlugField
を見てみましょう:
from django.forms import CharField
from django.core import validators
class SlugField(CharField):
default_validators = [validators.validate_slug]
見ての通り、SlugField
はカスタマイズされたバリデータを伴う CharField
で、このバリデータは送信されたテキストがいくつかの文字列ルールに従うかどうかを検証します。これはフィールド定義においても実装可能です:
slug = forms.SlugField()
これは以下と同じです:
slug = forms.CharField(validators=[validators.validate_slug])
一般的なケース (例えば、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 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(MultiEmailField, self).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.
Let’s create a simple ContactForm
to demonstrate how you’d use this
field:
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.
特定のフィールド属性をクリーニングする¶
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
互いに依存するフィールドをクリーニングして検証する¶
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(ContactForm, self).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."
)
In this code, if the validation error is raised, the form will display an error message at the top of the form (normally) describing the problem.
The call to super(ContactForm, self).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(ContactForm, self).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(ContactForm, self).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 ValidationError を発生させる for
more details. Note that add_error()
automatically removes the field
from cleaned_data
.