mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-07-06 10:49:17 +00:00
Code Issues 32 Releases Wiki Activity

[soc2009/model-validation] Minor edits to form validation docs.

Browse Source 
git-svn-id: http://code.djangoproject.com/svn/django/branches/soc2009/model-validation@12096 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Joseph Kocherhans 2010-01-05 01:21:41 +00:00
parent 73d7f4671b
commit 3e9035a962
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/ref/forms/validation.txt
View File

@ -25,8 +25,7 @@ of them to the form submitter, it is possible to pass a list of errors to the
Most validation can be done using `validators`_ - simple helpers that can be Most validation can be done using `validators`_ - simple helpers that can be
reused easily. Validators are simple functions (or callables) that take a single reused easily. Validators are simple functions (or callables) that take a single
argument and raise ``ValidationError`` on invalid input. Validators are run argument and raise ``ValidationError`` on invalid input. Validators are run
inside the ``run_validators`` method that is called from ``Field.clean`` once after the field's ``to_python`` and ``validate`` methods have been called.
the value is validated by the field's methods.
Validation of a Form is split into several steps, which can be customized or Validation of a Form is split into several steps, which can be customized or
overridden: overridden:
@ -38,15 +37,16 @@ overridden:
FloatField will turn the data into a Python ``float`` or raise a FloatField will turn the data into a Python ``float`` or raise a
``ValidationError``. ``ValidationError``.
* Next step resides in ``validate()`` method. This is a method where all * The ``validate()`` method on a Field handles field-specific validation
field-specific validation, that cannot be abstracted into a validator, that is not suitable for a validator, It takes the value coerced to
should take place. It takes the value coerced to correct datatype and correct datatype and raises ``ValidationError`` on any error. This method
raises ``ValidationError`` on any error. This method does not return does not return anything and shouldn't alter the value. You should
anything and shouldn't alter the value. override it to handle validation logic that you don't want to put in a
validator.
* Validators are run in the ``run_validators`` method. This method * The ``run_validators()`` method on a Field runs all of the field's
aggregates all the errors from all validators run into a single validators and aggregates all the errors into a single
``ValidationError``. ``ValidationError``. You shouldn't need to override this method.
* The ``clean()`` method on a Field subclass. This is responsible for * The ``clean()`` method on a Field subclass. This is responsible for
running ``to_python``, ``validate`` and ``run_validators`` in the correct running ``to_python``, ``validate`` and ``run_validators`` in the correct
@ -212,15 +212,15 @@ containing comma-separated e-mail addresses. The full class looks like this::
def to_python(self, value): def to_python(self, value):
"Normalize data to a list of strings." "Normalize data to a list of strings."
# return empty list on empty input # Return an empty list if no input was given.
if not value: return [] if not value:
return []
return value.split(',') return value.split(',')
def validate(self, value): def validate(self, value):
"Check if value consists only of valid emails." "Check if value consists only of valid emails."
# check if value is given if the field is required # Use the parent's handling of required fields, etc.
super(MultiEmailField, self).validate(value) super(MultiEmailField, self).validate(value)
for email in value: for email in value: