Add an append method to ErrorDict

[Thomas Güttler <hv@…>]

Custom Validation: If you need to access other fields, you
need to overwrite form.clean(). If you want to have
the error message near a widget (not all), you need to
modify the _error dict of the form.

To make this more user friendly I wrote a small patch:

ErrorDict.append(fieldname, message)

Doc patch included.

[Brian Rosner]

You can use the clean_FIELD() method validation hooks to get errors messages near fields.

[Thomas Güttler <hv@…>]

Thank you brosner, for looking at this patch. But I can't use clean_FIELD():

if clean_FIELD() requires to look at FIELD2, the dict self.cleaned_data does not contain
FIELD2. If you need the cleaned values of two fields for validation, you can not use clean_FIELD().

Nevertheless I want the error message to be near the field FIELD.

Here is how I use the patch:

    def clean(self):
        parent=self.cleaned_data.get("parent")
        name=self.cleaned_data.get("name")
        if ....:
            # Needs Django Patch #5335
            self.errors.append("name", u'...')
        return self.cleaned_data

Of course I could do this without the patch, too:

errorlist=self.errors.get(name) 
if errorlist==None: 
    errorlist=ErrorList() 
    self.errors[name]=errorlist 
errorlist.append(message) 

But that's too much code, I don't want to repeat. Maybe the documentation should
be updated, too.

[Thomas Güttler <hv@…>]

Added doctests

[Thomas Güttler]

Related django snippet: ​http://www.djangosnippets.org/snippets/1132/

[Alex Gaynor]

Perhaps a better method would be to have the ErrorDict be a defaultdict, that way users can do form._errorsfield.append('error message') without worrying about whether or not field is in the dict or not.

[Ivan Giuliani]

Attached patch implements ErrorDict as a defaultdict (can't inherit directly from defaultdict since it's new in 2.5 or 2.4, can't remember, but definitely not in 2.3). It would be helpful if someone could review the documentation part of the patch since I'm not a native english speaker.

[Ivan Giuliani]

updated patch, tests and documentation

[Alex Gaynor]

The docs look ok by me, 2 small things though, instead of self.has_key(field) do field in self . Also there's no need to use super() for setitem since it isn't overode in the subclass, you can actually just use setattr(self, field, []).

[Ivan Giuliani]

updated patch using setdefault

[Ivan Giuliani]

Even better, I used setdefault so in the end is a one-line patch.

[Alex Gaynor]

There's actually a slight disconnect between the docs and the code, the docs say an ErrorList is created, but getitem adds a list([]), I think an ErrorList would be the correct behavior.

[Ivan Giuliani]

Fixed patch, create an ErrorList instead of a simple list

[mrts]

According to Version1.1Features seems to be in scope for 1.1?

[jkocherhans]

Bumping to 1.2. For the record, I have to do this all the time and I'd like to see something like this, but I'm not entirely sold on this way yet.

[Simon Litchfield]

Definitely. Often views need to perform more involved steps *after* the form is validated; which may fail, and ultimately mean there was a problem with what was entered in the form.

There needs to be an easy, documented, encouraged way of appending errors to NON_FIELD_ERRORS as well as to specific fields; post-validation (ie from the view).

[Honza Král]

This approach is in conflict with #4752 ([6142]).

The method would either have to be on the Form class (not entirely insane). Another way how to propagate your error onto a field is using ComplexValidators present in model-validation branch, that way you don't have to worry about the internals of ErrorDict...

[jkocherhans]

This a a feature, so I'm bumping it to 1.3. Sorry. I'm assigning it to myself it to increase the chances that I'll remember it for the next cycle.

[Luke Plant]

Looks like Joseph didn't remember :-( This is a feature, so will have to wait again. Patch also needs updating (especially to use unittest rather than doctests).

[vbmendes]

Reviewed patch with unittests

[Julien Phalip]

Thanks a lot for updating the patch. I showed it to Alex and he wondered if you could write a test that verifies that doing errors['foo'] without actually altering it doesn't cause any problem?

[Karen Tracey]

Current patch (form_error_append_r16741.diff) will auto-create an ErrorList() object for a field's error list even if the including form has over-ridden the form's error class (​https://docs.djangoproject.com/en/1.3/ref/forms/api/#customizing-the-error-list-format). If we are going to add this (and it would be nice) it needs to be done in a way that will use the form's custom error class if it has been defined. This case should also be tested, in a test similar to: https://code.djangoproject.com/browser/django/tags/releases/1.3.1/tests/regressiontests/forms/tests/error_messages.py#L199

[Jacob]

Milestone 1.4 deleted

[loic84]

The problem is that ErrorDict should be ErrorList agnostic. The latest patch hardcodes the ErrorList type which can be customized at the form level with the error_class argument of Form.__init__() .

The Form.add_errors() method discussed here is IMO a much better approach.

[loic84]

Actually there is merit in making ErrorDict inherit from defaultdict.

PR ​https://github.com/django/django/pull/1481

[alasdair]

Looping through defaultdicts in templates can cause problems. See #16335. I believe this change will stop the following template snippet from working.

    <ul>
      {% for field, errors in form.errors.items %}
       <li>{{ field }}: {{errors}}
      {% endford %}
    </ul>

I realise it's a slightly artificial example, and that usually you would use {{ form.errors }}.

[Simon Litchfield]

Check out the ​related discussion and also ticket #20867

[loic84]

@alasdair: that looks like a nasty incompatibility with no obvious workaround.

The only reason I fixed this despite #20867 was so internally it wouldn't be needed to check if keys existed, it's clearly not worth breaking existing templates over this.

I think we should close this ticket as wontfix, especially now that another ticket addresses the main issue.

[Marc Tamlyn]

I agree that this is not the best way forwards. The ticket #20867 is now covering the Form.add_errors() approach. I'm going to close this ticket as a "duplicate" cos I think that's closest to what's happening.