Allow 'clean()' to specify the wrong field

An example of use:

    def clean(self):
        # Check the gateway is compatible with the address/mask
        gateway = self.cleaned_data['gateway']
        address = self.cleaned_data['address']
        netmask = self.cleaned_data['netmask']
        if not netconfig.addresses_match(address, gateway, netmask):
            raise forms.ValidationError(
                "Gateway not valid for the specified address",
                field='gateway')

You're missing the obvious solution - use a clean_field method (eg clean_email()). A field specific clean method can reference other entries from cleaned_data[] if necessary, and any error message will be associated with the field, rather than the form.

Russell: that does impose an ordering constraint, though -- dependencies done this way can only depend on fields before themselves.

I'd probably be +0 on the patch since it has no backwards compatibility impact. Alternatively, we could document how to add to Form._errors. Leaving closed for now, though.

Replying to russellm:

You're missing the obvious solution - use a clean_field method (eg clean_email()).

Not so obvious: when clean_email() is called you may not have yet the cleaned results of all the fields required for the composed validation.

Malcolm: Valid point about the ordering requirement, although I'm not convinced that it is a problem in practice. The error message needs to be tied to a specific field, and you can always set up the field order so that the field with the error is last.

This enforces an order for presentation that may not be natural, but only matters if you are rendering using form.as_*; if presentation order doesn't match logical order, you can manually render each field.

My rejection of this idea was based on the fact that it introduces a second way to raise field errors. However, I'm only a -0. Regardless, better documentation of Form._errors is probably a good idea.

Replying to russellm:

My rejection of this idea was based on the fact that it introduces a second way to raise field errors. However, I'm only a -0. Regardless, better documentation of Form._errors is probably a good idea.

Are you sure exposing Form._errors is a good idea? Currently it is an implementation detail (at least for people developing form logic): exposing it in the API is an implementation leak that would tie the current implementation to everybody's form logic.

Adding an optional field to the exception is a (mostly harmless) extension of the current interface.

The other point is that when you are composing forms from multiple base forms, you don't always have direct control over ordering unless you redeclare fields (which defeats the purpose of multiple base forms in part).

Considering the strong points given, shouldn't this be reopened? I for one would like to use it like in the example above, rather than having to depend on field ordering.

I'm also using this in my projects, so I modified the patch to add tests and documentation (within the tests).

I think it is more clear to use field_name instead of field in the exception (using field is against the DON'T MAKE ME THINK principle: what's a field? instance? name?).

Find the patch attached.

Improved patch against [7321] that appends errors from clean() to base field errors.

Appends errors from clean() to original errors.

Given the currently active discussion on django-dev regarding changes to model and form validation (including some renaming), let's sit on this for a bit.