- Language:en
Form and field validation¶
Form validation happens when the data is cleaned. If you want to customizethis process, there are various places to make changes, each one serving adifferent purpose. Three types of cleaning methods are run during formprocessing. These are normally executed when you call theis_valid()method on a form. There are other things that can also trigger cleaning andvalidation (accessing theerrors attribute or callingfull_clean()directly), but normally they won’t be needed.
In general, any cleaning method can raiseValidationError if there is aproblem with the data it is processing, passing the relevant information to theValidationError constructor.See belowfor the best practice in raisingValidationError. If noValidationErroris raised, the method should return the cleaned (normalized) data as a Pythonobject.
Most validation can be done usingvalidators - helpers that can be reused.Validators are functions (or callables) that take a single argument and raiseValidationError on invalid input. Validators are run after the field’sto_python andvalidate methods have been called.
Validation of a form is split into several steps, which can be customized oroverridden:
The
to_python()method on aFieldis the first step in everyvalidation. It coerces the value to a correct datatype and raisesValidationErrorif that is not possible. This method accepts the rawvalue from the widget and returns the converted value. For example, aFloatFieldwill turn the data into a Pythonfloator raise aValidationError.The
validate()method on aFieldhandles field-specific validationthat is not suitable for a validator. It takes a value that has beencoerced to a correct datatype and raisesValidationErroron any error.This method does not return anything and shouldn’t alter the value. Youshould override it to handle validation logic that you can’t or don’twant to put in a validator.The
run_validators()method on aFieldruns all of the field’svalidators and aggregates all the errors into a singleValidationError. You shouldn’t need to override this method.The
clean()method on aFieldsubclass is responsible for runningto_python(),validate(), andrun_validators()in the correctorder and propagating their errors. If, at any time, any of the methodsraiseValidationError, the validation stops and that error is raised.This method returns the clean data, which is then inserted into thecleaned_datadictionary 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 particularattribute, unrelated to the type of field that it is. This method is notpassed any parameters. You will need to look up the value of the fieldinself.cleaned_dataand remember that it will be a Python objectat this point, not the original string submitted in the form (it will beincleaned_databecause the general fieldclean()method, above,has already cleaned the data once).For example, if you wanted to validate that the contents of a
CharFieldcalledserialnumberwas unique,clean_serialnumber()would be the right place to do this. You don’tneed a specific field (it’s aCharField), but you want aformfield-specific piece of validation and, possibly, cleaning/normalizingthe data.The return value of this method replaces the existing value in
cleaned_data, so it must be the field’s value fromcleaned_data(evenif this method didn’t change it) or a new cleaned value.The form subclass’s
clean()method can perform validation that requiresaccess to multiple form fields. This is where you might put in checks such as“if fieldAis supplied, fieldBmust contain a valid email address”.This method can return a completely different dictionary if it wishes, whichwill be used as thecleaned_data.Since the field validation methods have been run by the time
clean()iscalled, you also have access to the form’serrorsattribute whichcontains all the errors raised by cleaning of individual fields.Note that any errors raised by your
Form.clean()override will notbe 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 youwant to attach errors to a specific field in the form, you need to calladd_error().Also note that there are special considerations when overridingthe
clean()method of aModelFormsubclass. (see theModelForm 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 formdefinition), theField.clean() method (or its override) is run, thenclean_<fieldname>(). Finally, once those two methods are run for everyfield, theForm.clean() method, or its override, is executed whetheror not the previous methods have raised errors.
Examples of each of these methods are provided below.
As mentioned, any of these methods can raise aValidationError. For anyfield, if theField.clean() method raises aValidationError, anyfield-specific cleaning method is not called. However, the cleaning methodsfor all remaining fields are still executed.
RaisingValidationError¶
In order to make error messages flexible and easy to override, consider thefollowing guidelines:
Provide a descriptive error
codeto the constructor:# GoodValidationError(_("Invalid value"),code="invalid")# BadValidationError(_("Invalid value"))
Don’t coerce variables into the message; use placeholders and the
paramsargument of the constructor:# GoodValidationError(_("Invalid value:%(value)s"),params={"value":"42"},)# BadValidationError(_("Invalid value:%s")%value)
Use mapping keys instead of positional formatting. This enables puttingthe variables in any order or omitting them altogether when rewriting themessage:
# GoodValidationError(_("Invalid value:%(value)s"),params={"value":"42"},)# BadValidationError(_("Invalid value:%s"),params=("42",),)
Wrap the message with
gettextto enable translation:# GoodValidationError(_("Invalid value"))# BadValidationError("Invalid value")
Putting it all together:
raiseValidationError(_("Invalid value:%(value)s"),code="invalid",params={"value":"42"},)
Following these guidelines is particularly necessary if you write reusableforms, form fields, and model fields.
While not recommended, if you are at the end of the validation chain(i.e. your formclean() method) and you know you willnever needto override your error message you can still opt for the less verbose:
ValidationError(_("Invalid value:%s")%value)
TheForm.errors.as_data() andForm.errors.as_json() methodsgreatly benefit from fully featuredValidationErrors (with acode nameand aparams dictionary).
Raising multiple errors¶
If you detect multiple errors during a cleaning method and wish to signal allof them to the form submitter, it is possible to pass a list of errors to theValidationError constructor.
As above, it is recommended to pass a list ofValidationError instanceswithcodes andparams but a list of strings will also work:
# GoodraiseValidationError([ValidationError(_("Error 1"),code="error1"),ValidationError(_("Error 2"),code="error2"),])# BadraiseValidationError([_("Error 1"),_("Error 2"),])
Using validation in practice¶
The previous sections explained how validation works in general for forms.Since it can sometimes be easier to put things into place by seeing eachfeature in use, here are a series of small examples that use each of theprevious features.
Using validators¶
Django’s form (and model) fields support use of utility functions and classesknown as validators. A validator is a callable object or function that takes avalue and returns nothing if the value is valid or raises aValidationError if not. These can be passed to afield’s constructor, via the field’svalidators argument, or defined on theField class itself with thedefault_validatorsattribute.
Validators can be used to validate values inside the field, let’s have a lookat Django’sSlugField:
fromdjango.coreimportvalidatorsfromdjango.formsimportCharFieldclassSlugField(CharField):default_validators=[validators.validate_slug]
As you can see,SlugField is aCharField with a customized validatorthat validates that submitted text obeys to some character rules. This can alsobe done on field definition so:
slug=forms.SlugField()
is equivalent to:
slug=forms.CharField(validators=[validators.validate_slug])
Common cases such as validating against an email or a regular expression can behandled using existing validator classes available in Django. For example,validators.validate_slug is an instance ofaRegexValidator constructed with the firstargument being the pattern:^[-a-zA-Z0-9_]+\Z. See the section onwriting validators to see a list of what is alreadyavailable and for an example of how to write a validator.
Form field default cleaning¶
Let’s first create a custom form field that validates its input is a stringcontaining comma-separated email addresses. The full class looks like this:
fromdjangoimportformsfromdjango.core.validatorsimportvalidate_emailclassMultiEmailField(forms.Field):defto_python(self,value):"""Normalize data to a list of strings."""# Return an empty list if no input was given.ifnotvalue:return[]returnvalue.split(",")defvalidate(self,value):"""Check if value consists only of valid emails."""# Use the parent's handling of required fields, etc.super().validate(value)foremailinvalue:validate_email(email)
Every form that uses this field will have these methods run before anythingelse can be done with the field’s data. This is cleaning that is specific tothis type of field, regardless of how it is subsequently used.
Let’s create aContactForm to demonstrate how you’d use this field:
classContactForm(forms.Form):subject=forms.CharField(max_length=100)message=forms.CharField()sender=forms.EmailField()recipients=MultiEmailField()cc_myself=forms.BooleanField(required=False)
UseMultiEmailField like any other form field. When theis_valid()method is called on the form, theMultiEmailField.clean() method will berun as part of the cleaning process and it will, in turn, call the customto_python() andvalidate() methods.
Cleaning a specific field attribute¶
Continuing on from the previous example, suppose that in ourContactForm,we want to make sure that therecipients field always contains the address"fred@example.com". This is validation that is specific to our form, so wedon’t want to put it into the generalMultiEmailField class. Instead, wewrite a cleaning method that operates on therecipients field, like so:
fromdjangoimportformsfromdjango.core.exceptionsimportValidationErrorclassContactForm(forms.Form):# Everything as before....defclean_recipients(self):data=self.cleaned_data["recipients"]if"fred@example.com"notindata:raiseValidationError("You have forgotten about Fred!")# Always return a value to use as the new cleaned data, even if# this method didn't change it.returndata
Cleaning and validating fields that depend on each other¶
Suppose we add another requirement to our contact form: if thecc_myselffield isTrue, thesubject must contain the word"help". We areperforming validation on more than one field at a time, so the form’sclean() method is a good spot to do this. Notice that we aretalking about theclean() method on the form here, whereas earlier we werewriting aclean() method on a field. It’s important to keep the field andform difference clear when working out where to validate things. Fields aresingle data points, forms are a collection of fields.
By the time the form’sclean() method is called, all the individual fieldclean methods will have been run (the previous two sections), soself.cleaned_data will be populated with any data that has survived sofar. So you also need to remember to allow for the fact that the fields youare wanting to validate might not have survived the initial individual fieldchecks.
There are two ways to report any errors from this step. Probably the mostcommon method is to display the error at the top of the form. To create suchan error, you can raise aValidationError from theclean() method. Forexample:
fromdjangoimportformsfromdjango.core.exceptionsimportValidationErrorclassContactForm(forms.Form):# Everything as before....defclean(self):cleaned_data=super().clean()cc_myself=cleaned_data.get("cc_myself")subject=cleaned_data.get("subject")ifcc_myselfandsubject:# Only do something if both fields are valid so far.if"help"notinsubject:raiseValidationError("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 anerror message at the top of the form (normally) describing the problem. Sucherrors are non-field errors, which are displayed in the template with{{form.non_field_errors}}.
The call tosuper().clean() in the example code ensures that any validationlogic in parent classes is maintained. If your form inherits another thatdoesn’t return acleaned_data dictionary in itsclean() method (doingso is optional), then don’t assigncleaned_data to the result of thesuper() call and useself.cleaned_data instead:
defclean(self):super().clean()cc_myself=self.cleaned_data.get("cc_myself")...
The second approach for reporting validation errors might involve assigning theerror message to one of the fields. In this case, let’s assign an error messageto both the “subject” and “cc_myself” rows in the form display. Be careful whendoing this in practice, since it can lead to confusing form output. We’reshowing what is possible here and leaving it up to you and your designers towork out what works effectively in your particular situation. Our new code(replacing the previous sample) looks like this:
fromdjangoimportformsclassContactForm(forms.Form):# Everything as before....defclean(self):cleaned_data=super().clean()cc_myself=cleaned_data.get("cc_myself")subject=cleaned_data.get("subject")ifcc_myselfandsubjectand"help"notinsubject:msg="Must put 'help' in subject when cc'ing yourself."self.add_error("cc_myself",msg)self.add_error("subject",msg)
The second argument ofadd_error() can be a string, or preferably aninstance ofValidationError. SeeRaising ValidationError for moredetails. Note thatadd_error() automatically removes the field fromcleaned_data.
