PageRenderTime 39ms CodeModel.GetById 14ms RepoModel.GetById 0ms app.codeStats 0ms

Plain Text | 366 lines | 288 code | 78 blank | 0 comment | 0 complexity | 2526aa335e5cbcde90cccf56d29b5d0f MD5 | raw file
Possible License(s): BSD-3-Clause
  1. Form and field validation
  2. =========================
  3. .. versionchanged:: 1.2
  4. Form validation happens when the data is cleaned. If you want to customize
  5. this process, there are various places you can change, each one serving a
  6. different purpose. Three types of cleaning methods are run during form
  7. processing. These are normally executed when you call the ``is_valid()``
  8. method on a form. There are other things that can trigger cleaning and
  9. validation (accessing the ``errors`` attribute or calling ``full_clean()``
  10. directly), but normally they won't be needed.
  11. In general, any cleaning method can raise ``ValidationError`` if there is a
  12. problem with the data it is processing, passing the relevant error message to
  13. the ``ValidationError`` constructor. If no ``ValidationError`` is raised, the
  14. method should return the cleaned (normalized) data as a Python object.
  15. If you detect multiple errors during a cleaning method and wish to signal all
  16. of them to the form submitter, it is possible to pass a list of errors to the
  17. ``ValidationError`` constructor.
  18. Most validation can be done using `validators`_ - simple helpers that can be
  19. reused easily. Validators are simple functions (or callables) that take a single
  20. argument and raise ``ValidationError`` on invalid input. Validators are run
  21. after the field's ``to_python`` and ``validate`` methods have been called.
  22. Validation of a Form is split into several steps, which can be customized or
  23. overridden:
  24. * The ``to_python()`` method on a Field is the first step in every
  25. validation. It coerces the value to correct datatype and raises
  26. ``ValidationError`` if that is not possible. This method accepts the raw
  27. value from the widget and returns the converted value. For example, a
  28. FloatField will turn the data into a Python ``float`` or raise a
  29. ``ValidationError``.
  30. * The ``validate()`` method on a Field handles field-specific validation
  31. that is not suitable for a validator, It takes a value that has been
  32. coerced to correct datatype and raises ``ValidationError`` on any error.
  33. This method does not return anything and shouldn't alter the value. You
  34. should override it to handle validation logic that you can't or don't
  35. want to put in a validator.
  36. * The ``run_validators()`` method on a Field runs all of the field's
  37. validators and aggregates all the errors into a single
  38. ``ValidationError``. You shouldn't need to override this method.
  39. * The ``clean()`` method on a Field subclass. This is responsible for
  40. running ``to_python``, ``validate`` and ``run_validators`` in the correct
  41. order and propagating their errors. If, at any time, any of the methods
  42. raise ``ValidationError``, the validation stops and that error is raised.
  43. This method returns the clean data, which is then inserted into the
  44. ``cleaned_data`` dictionary of the form.
  45. * The ``clean_<fieldname>()`` method in a form subclass -- where
  46. ``<fieldname>`` is replaced with the name of the form field attribute.
  47. This method does any cleaning that is specific to that particular
  48. attribute, unrelated to the type of field that it is. This method is not
  49. passed any parameters. You will need to look up the value of the field
  50. in ``self.cleaned_data`` and remember that it will be a Python object
  51. at this point, not the original string submitted in the form (it will be
  52. in ``cleaned_data`` because the general field ``clean()`` method, above,
  53. has already cleaned the data once).
  54. For example, if you wanted to validate that the contents of a
  55. ``CharField`` called ``serialnumber`` was unique,
  56. ``clean_serialnumber()`` would be the right place to do this. You don't
  57. need a specific field (it's just a ``CharField``), but you want a
  58. formfield-specific piece of validation and, possibly,
  59. cleaning/normalizing the data.
  60. Just like the general field ``clean()`` method, above, this method
  61. should return the cleaned data, regardless of whether it changed
  62. anything or not.
  63. * The Form subclass's ``clean()`` method. This method can perform
  64. any validation that requires access to multiple fields from the form at
  65. once. This is where you might put in things to check that if field ``A``
  66. is supplied, field ``B`` must contain a valid e-mail address and the
  67. like. The data that this method returns is the final ``cleaned_data``
  68. attribute for the form, so don't forget to return the full list of
  69. cleaned data if you override this method (by default, ``Form.clean()``
  70. just returns ``self.cleaned_data``).
  71. Note that any errors raised by your ``Form.clean()`` override will not
  72. be associated with any field in particular. They go into a special
  73. "field" (called ``__all__``), which you can access via the
  74. ``non_field_errors()`` method if you need to. If you want to attach
  75. errors to a specific field in the form, you will need to access the
  76. ``_errors`` attribute on the form, which is `described later`_.
  77. Also note that there are special considerations when overriding
  78. the ``clean()`` method of a ``ModelForm`` subclass. (see the
  79. :ref:`ModelForm documentation
  80. <overriding-modelform-clean-method>` for more information)
  81. These methods are run in the order given above, one field at a time. That is,
  82. for each field in the form (in the order they are declared in the form
  83. definition), the ``Field.clean()`` method (or its override) is run, then
  84. ``clean_<fieldname>()``. Finally, once those two methods are run for every
  85. field, the ``Form.clean()`` method, or its override, is executed.
  86. Examples of each of these methods are provided below.
  87. As mentioned, any of these methods can raise a ``ValidationError``. For any
  88. field, if the ``Field.clean()`` method raises a ``ValidationError``, any
  89. field-specific cleaning method is not called. However, the cleaning methods
  90. for all remaining fields are still executed.
  91. The ``clean()`` method for the ``Form`` class or subclass is always run. If
  92. that method raises a ``ValidationError``, ``cleaned_data`` will be an empty
  93. dictionary.
  94. The previous paragraph means that if you are overriding ``Form.clean()``, you
  95. should iterate through ``self.cleaned_data.items()``, possibly considering the
  96. ``_errors`` dictionary attribute on the form as well. In this way, you will
  97. already know which fields have passed their individual validation requirements.
  98. .. _described later:
  99. Form subclasses and modifying field errors
  100. ------------------------------------------
  101. Sometimes, in a form's ``clean()`` method, you will want to add an error
  102. message to a particular field in the form. This won't always be appropriate
  103. and the more typical situation is to raise a ``ValidationError`` from
  104. ``Form.clean()``, which is turned into a form-wide error that is available
  105. through the ``Form.non_field_errors()`` method.
  106. When you really do need to attach the error to a particular field, you should
  107. store (or amend) a key in the ``Form._errors`` attribute. This attribute is an
  108. instance of a ``django.forms.util.ErrorDict`` class. Essentially, though, it's
  109. just a dictionary. There is a key in the dictionary for each field in the form
  110. that has an error. Each value in the dictionary is a
  111. ``django.forms.util.ErrorList`` instance, which is a list that knows how to
  112. display itself in different ways. So you can treat ``_errors`` as a dictionary
  113. mapping field names to lists.
  114. If you want to add a new error to a particular field, you should check whether
  115. the key already exists in ``self._errors`` or not. If not, create a new entry
  116. for the given key, holding an empty ``ErrorList`` instance. In either case,
  117. you can then append your error message to the list for the field name in
  118. question and it will be displayed when the form is displayed.
  119. There is an example of modifying ``self._errors`` in the following section.
  120. .. admonition:: What's in a name?
  121. You may be wondering why is this attribute called ``_errors`` and not
  122. ``errors``. Normal Python practice is to prefix a name with an underscore
  123. if it's not for external usage. In this case, you are subclassing the
  124. ``Form`` class, so you are essentially writing new internals. In effect,
  125. you are given permission to access some of the internals of ``Form``.
  126. Of course, any code outside your form should never access ``_errors``
  127. directly. The data is available to external code through the ``errors``
  128. property, which populates ``_errors`` before returning it).
  129. Another reason is purely historical: the attribute has been called
  130. ``_errors`` since the early days of the forms module and changing it now
  131. (particularly since ``errors`` is used for the read-only property name)
  132. would be inconvenient for a number of reasons. You can use whichever
  133. explanation makes you feel more comfortable. The result is the same.
  134. Using validation in practice
  135. ----------------------------
  136. The previous sections explained how validation works in general for forms.
  137. Since it can sometimes be easier to put things into place by seeing each
  138. feature in use, here are a series of small examples that use each of the
  139. previous features.
  140. .. _validators:
  141. Using validators
  142. ~~~~~~~~~~~~~~~~
  143. .. versionadded:: 1.2
  144. Django's form (and model) fields support use of simple utility functions and
  145. classes known as validators. These can be passed to a field's constructor, via
  146. the field's ``validators`` argument, or defined on the Field class itself with
  147. the ``default_validators`` attribute.
  148. Simple validators can be used to validate values inside the field, let's have
  149. a look at Django's ``EmailField``::
  150. class EmailField(CharField):
  151. default_error_messages = {
  152. 'invalid': _(u'Enter a valid e-mail address.'),
  153. }
  154. default_validators = [validators.validate_email]
  155. As you can see, ``EmailField`` is just a ``CharField`` with customized error
  156. message and a validator that validates e-mail addresses. This can also be done
  157. on field definition so::
  158. email = forms.EmailField()
  159. is equivalent to::
  160. email = forms.CharField(validators=[validators.validate_email],
  161. error_messages={'invalid': _(u'Enter a valid e-mail address.')})
  162. Form field default cleaning
  163. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  164. Let's firstly create a custom form field that validates its input is a string
  165. containing comma-separated e-mail addresses. The full class looks like this::
  166. from django import forms
  167. from django.core.validators import validate_email
  168. class MultiEmailField(forms.Field):
  169. def to_python(self, value):
  170. "Normalize data to a list of strings."
  171. # Return an empty list if no input was given.
  172. if not value:
  173. return []
  174. return value.split(',')
  175. def validate(self, value):
  176. "Check if value consists only of valid emails."
  177. # Use the parent's handling of required fields, etc.
  178. super(MultiEmailField, self).validate(value)
  179. for email in value:
  180. validate_email(email)
  181. Every form that uses this field will have these methods run before anything
  182. else can be done with the field's data. This is cleaning that is specific to
  183. this type of field, regardless of how it is subsequently used.
  184. Let's create a simple ``ContactForm`` to demonstrate how you'd use this
  185. field::
  186. class ContactForm(forms.Form):
  187. subject = forms.CharField(max_length=100)
  188. message = forms.CharField()
  189. sender = forms.EmailField()
  190. recipients = MultiEmailField()
  191. cc_myself = forms.BooleanField(required=False)
  192. Simply use ``MultiEmailField`` like any other form field. When the
  193. ``is_valid()`` method is called on the form, the ``MultiEmailField.clean()``
  194. method will be run as part of the cleaning process and it will, in turn, call
  195. the custom ``to_python()`` and ``validate()`` methods.
  196. Cleaning a specific field attribute
  197. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  198. Continuing on from the previous example, suppose that in our ``ContactForm``,
  199. we want to make sure that the ``recipients`` field always contains the address
  200. ``""``. This is validation that is specific to our form, so we
  201. don't want to put it into the general ``MultiEmailField`` class. Instead, we
  202. write a cleaning method that operates on the ``recipients`` field, like so::
  203. class ContactForm(forms.Form):
  204. # Everything as before.
  205. ...
  206. def clean_recipients(self):
  207. data = self.cleaned_data['recipients']
  208. if "" not in data:
  209. raise forms.ValidationError("You have forgotten about Fred!")
  210. # Always return the cleaned data, whether you have changed it or
  211. # not.
  212. return data
  213. Cleaning and validating fields that depend on each other
  214. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  215. Suppose we add another requirement to our contact form: if the ``cc_myself``
  216. field is ``True``, the ``subject`` must contain the word ``"help"``. We are
  217. performing validation on more than one field at a time, so the form's
  218. ``clean()`` method is a good spot to do this. Notice that we are talking about
  219. the ``clean()`` method on the form here, whereas earlier we were writing a
  220. ``clean()`` method on a field. It's important to keep the field and form
  221. difference clear when working out where to validate things. Fields are single
  222. data points, forms are a collection of fields.
  223. By the time the form's ``clean()`` method is called, all the individual field
  224. clean methods will have been run (the previous two sections), so
  225. ``self.cleaned_data`` will be populated with any data that has survived so
  226. far. So you also need to remember to allow for the fact that the fields you
  227. are wanting to validate might not have survived the initial individual field
  228. checks.
  229. There are two ways to report any errors from this step. Probably the most
  230. common method is to display the error at the top of the form. To create such
  231. an error, you can raise a ``ValidationError`` from the ``clean()`` method. For
  232. example::
  233. class ContactForm(forms.Form):
  234. # Everything as before.
  235. ...
  236. def clean(self):
  237. cleaned_data = self.cleaned_data
  238. cc_myself = cleaned_data.get("cc_myself")
  239. subject = cleaned_data.get("subject")
  240. if cc_myself and subject:
  241. # Only do something if both fields are valid so far.
  242. if "help" not in subject:
  243. raise forms.ValidationError("Did not send for 'help' in "
  244. "the subject despite CC'ing yourself.")
  245. # Always return the full collection of cleaned data.
  246. return cleaned_data
  247. In this code, if the validation error is raised, the form will display an
  248. error message at the top of the form (normally) describing the problem.
  249. The second approach might involve assigning the error message to one of the
  250. fields. In this case, let's assign an error message to both the "subject" and
  251. "cc_myself" rows in the form display. Be careful when doing this in practice,
  252. since it can lead to confusing form output. We're showing what is possible
  253. here and leaving it up to you and your designers to work out what works
  254. effectively in your particular situation. Our new code (replacing the previous
  255. sample) looks like this::
  256. class ContactForm(forms.Form):
  257. # Everything as before.
  258. ...
  259. def clean(self):
  260. cleaned_data = self.cleaned_data
  261. cc_myself = cleaned_data.get("cc_myself")
  262. subject = cleaned_data.get("subject")
  263. if cc_myself and subject and "help" not in subject:
  264. # We know these are not in self._errors now (see discussion
  265. # below).
  266. msg = u"Must put 'help' in subject when cc'ing yourself."
  267. self._errors["cc_myself"] = self.error_class([msg])
  268. self._errors["subject"] = self.error_class([msg])
  269. # These fields are no longer valid. Remove them from the
  270. # cleaned data.
  271. del cleaned_data["cc_myself"]
  272. del cleaned_data["subject"]
  273. # Always return the full collection of cleaned data.
  274. return cleaned_data
  275. As you can see, this approach requires a bit more effort, not withstanding the
  276. extra design effort to create a sensible form display. The details are worth
  277. noting, however. Firstly, earlier we mentioned that you might need to check if
  278. the field name keys already exist in the ``_errors`` dictionary. In this case,
  279. since we know the fields exist in ``self.cleaned_data``, they must have been
  280. valid when cleaned as individual fields, so there will be no corresponding
  281. entries in ``_errors``.
  282. Secondly, once we have decided that the combined data in the two fields we are
  283. considering aren't valid, we must remember to remove them from the
  284. ``cleaned_data``.
  285. In fact, Django will currently completely wipe out the ``cleaned_data``
  286. dictionary if there are any errors in the form. However, this behavior may
  287. change in the future, so it's not a bad idea to clean up after yourself in the
  288. first place.