Fixed #21894 -- Corrected a form.clean() example in case a superclass doesn't return data.
This commit is contained in:
parent
12aeed8c94
commit
80855a4b37
|
@ -371,16 +371,24 @@ example::
|
||||||
In this code, if the validation error is raised, the form will display an
|
In this code, if the validation error is raised, the form will display an
|
||||||
error message at the top of the form (normally) describing the problem.
|
error message at the top of the form (normally) describing the problem.
|
||||||
|
|
||||||
Note that the call to ``super(ContactForm, self).clean()`` in the example code
|
The call to ``super(ContactForm, self).clean()`` in the example code ensures
|
||||||
ensures that any validation logic in parent classes is maintained.
|
that any validation logic in parent classes is maintained. If your form
|
||||||
|
inherits another that doesn't return a ``cleaned_data`` dictionary in its
|
||||||
|
``clean()`` method (doing so is optional), then don't assign ``cleaned_data``
|
||||||
|
to the result of the ``super()`` call and use ``self.cleaned_data`` instead::
|
||||||
|
|
||||||
The second approach might involve assigning the error message to one of the
|
def clean(self):
|
||||||
fields. In this case, let's assign an error message to both the "subject" and
|
super(ContactForm, self).clean()
|
||||||
"cc_myself" rows in the form display. Be careful when doing this in practice,
|
cc_myself = self.cleaned_data.get("cc_myself")
|
||||||
since it can lead to confusing form output. We're showing what is possible
|
...
|
||||||
here and leaving it up to you and your designers to work out what works
|
|
||||||
effectively in your particular situation. Our new code (replacing the previous
|
The second approach for reporting validation errors might involve assigning the
|
||||||
sample) looks like this::
|
error message to one of the fields. In this case, let's assign an error message
|
||||||
|
to both the "subject" and "cc_myself" rows in the form display. Be careful when
|
||||||
|
doing this in practice, since it can lead to confusing form output. We're
|
||||||
|
showing what is possible here and leaving it up to you and your designers to
|
||||||
|
work out what works effectively in your particular situation. Our new code
|
||||||
|
(replacing the previous sample) looks like this::
|
||||||
|
|
||||||
from django import forms
|
from django import forms
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue