mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-01-20 23:29:17 +00:00
Code Issues 32 Releases Wiki Activity

Fixed #9902 -- Corrected misspelling in form validation documentation, thanks zunzun.

Browse Source 
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9674 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Gary Wilson Jr 2008-12-23 04:13:14 +00:00
parent bcae5fc1b3
commit 05737128de
1 changed files with 2 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -122,7 +122,7 @@ There is an example of modifying ``self._errors`` in the following section.
if it's not for external usage. In this case, you are subclassing the if it's not for external usage. In this case, you are subclassing the
``Form`` class, so you are essentially writing new internals. In effect, ``Form`` class, so you are essentially writing new internals. In effect,
you are given permission to access some of the internals of ``Form``. you are given permission to access some of the internals of ``Form``.
Of course, any code outside your form should never access ``_errors`` Of course, any code outside your form should never access ``_errors``
directly. The data is available to external code through the ``errors`` directly. The data is available to external code through the ``errors``
property, which populates ``_errors`` before returning it). property, which populates ``_errors`` before returning it).
@ -291,7 +291,7 @@ extra design effort to create a sensible form display. The details are worth
noting, however. Firstly, earlier we mentioned that you might need to check if noting, however. Firstly, earlier we mentioned that you might need to check if
the field name keys already exist in the ``_errors`` dictionary. In this case, the field name keys already exist in the ``_errors`` dictionary. In this case,
since we know the fields exist in ``self.cleaned_data``, they must have been since we know the fields exist in ``self.cleaned_data``, they must have been
valid when cleaned as individual fields, so there will be no corresonding valid when cleaned as individual fields, so there will be no corresponding
entries in ``_errors``. entries in ``_errors``.
Secondly, once we have decided that the combined data in the two fields we are Secondly, once we have decided that the combined data in the two fields we are
@ -302,4 +302,3 @@ In fact, Django will currently completely wipe out the ``cleaned_data``
dictionary if there are any errors in the form. However, this behaviour may dictionary if there are any errors in the form. However, this behaviour may
change in the future, so it's not a bad idea to clean up after yourself in the change in the future, so it's not a bad idea to clean up after yourself in the
first place. first place.