diff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt index f2136b202d..8a5303710a 100644 --- a/docs/ref/forms/api.txt +++ b/docs/ref/forms/api.txt @@ -173,7 +173,8 @@ from a view. The ``field`` argument is the name of the field to which the errors should be added. If its value is ``None`` the error will be treated as -a non-field error as returned by ``Form.non_field_errors()``. +a non-field error as returned by :meth:`Form.non_field_errors() +`. The ``error`` argument can be a simple string, or preferably an instance of ``ValidationError``. See :ref:`raising-validation-error` for best practices @@ -193,6 +194,14 @@ if the field contains any errors at all. To check for non-field errors use :data:`~django.core.exceptions.NON_FIELD_ERRORS` as the ``field`` parameter. +.. method:: Form.non_field_errors() + +This method returns the list of errors from :attr:`Form.errors +` that aren't associated with a particular field. +This includes ``ValidationError``\s that are raised in :meth:`Form.clean() +` and errors added using :meth:`Form.add_error(None, +"...") `. + Behavior of unbound forms ~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/ref/forms/validation.txt b/docs/ref/forms/validation.txt index 13c1e5a68d..63fc6f2658 100644 --- a/docs/ref/forms/validation.txt +++ b/docs/ref/forms/validation.txt @@ -85,8 +85,8 @@ overridden: Note that any errors raised by your ``Form.clean()`` override will not be associated with any field in particular. They go into a special "field" (called ``__all__``), which you can access via the - ``non_field_errors()`` method if you need to. If you want to attach - errors to a specific field in the form, you need to call + :meth:`~django.forms.Form.non_field_errors` method if you need to. If you + want to attach errors to a specific field in the form, you need to call :meth:`~django.forms.Form.add_error()`. Also note that there are special considerations when overriding @@ -329,7 +329,7 @@ form's ``clean()`` method, in which case you can use :meth:`~django.forms.Form.add_error()`. Note that this won't always be appropriate and the more typical situation is to raise a ``ValidationError`` from , which is turned into a form-wide error that is available through the -``Form.non_field_errors()`` method. +:meth:`Form.non_field_errors() ` method. Cleaning and validating fields that depend on each other ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt index f56cbee861..30eec42bbd 100644 --- a/docs/topics/testing/tools.txt +++ b/docs/topics/testing/tools.txt @@ -1269,7 +1269,8 @@ your test suite. ``field`` is the name of the field on the form to check. If ``field`` has a value of ``None``, non-field errors (errors you can access via - ``form.non_field_errors()``) will be checked. + :meth:`form.non_field_errors() `) will + be checked. ``errors`` is an error string, or a list of error strings, that are expected as a result of form validation. @@ -1288,7 +1289,8 @@ your test suite. ``field`` is the name of the field on the form to check. If ``field`` has a value of ``None``, non-field errors (errors you can access via - ``form.non_field_errors()``) will be checked. + :meth:`form.non_field_errors() `) will + be checked. ``errors`` is an error string, or a list of error strings, that are expected as a result of form validation.