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

[1.0.X] Fixed #9902 -- Corrected misspelling in form validation documentation, thanks zunzun.

Browse Source 
Backport of r9674 from trunk.


git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@9675 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Gary Wilson Jr 2008-12-23 04:14:51 +00:00
parent 47de671948
commit 44239004db
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
``Form`` class, so you are essentially writing new internals. In effect,
you are given permission to access some of the internals of ``Form``.
Of course, any code outside your form should never access ``_errors``
directly. The data is available to external code through the ``errors``
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
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
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``.
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
change in the future, so it's not a bad idea to clean up after yourself in the
first place.