Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#6705 closed (invalid)

When using {{ form.errors }} in a template, the output uses field name instead of using field label.

Reported by: Emilian Owned by: nobody
Component: Forms Version: dev
Severity: Keywords: errordict
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The ErrorDict has the field name as the key and the error messages as the value. When outputting the {{ form.errors }} in a template it displays the field name and then the error. This results in ugly, unreadable field names such as "your_field_name" followed by the errors. This occurs despite having set a verbose_name in the model declaration.

Change History (8)

comment:1 by Emilian, 17 years ago

comment:2 by James Bennett, 17 years ago

Resolution: invalid
Status: newclosed

The newforms docs explain how to customize error output; meanwhile, using the field name as the key in the errors dictionary is correct behavior, because it ensures consistency; using a verbose name or label is problematic because these may well be translated strings, and so will change from one page view to the next, wreaking havoc on code which wants to predictably access specific field errors.

in reply to:  2 comment:3 by Emilian, 17 years ago

Resolution: invalid
Status: closedreopened

Replying to ubernostrum:

The newforms docs explain how to customize error output; meanwhile, using the field name as the key in the errors dictionary is correct behavior, because it ensures consistency; using a verbose name or label is problematic because these may well be translated strings, and so will change from one page view to the next, wreaking havoc on code which wants to predictably access specific field errors.

Nobody said that the field name as a key is incorrect behavior or should be changed in this ticket. The ticket has to do with the fact that you cannot customize the display for form.errors because all that it contains is the field name as the key and the messages as the values. If I want to display all of the errors at the top of the form then it should display them using a verbose name (label) and not field_name_here.

There's been several IRC members who have observed the same behavior, expecting that {{ form.errors }} would display a nicely-formatted list of fields with the errors underneath. Instead they are getting field_name_here.

I propose having the field name as the key but the value as a dictionary which has two more keys: "label" and then "errors".

comment:4 by James Bennett, 17 years ago

Resolution: invalid
Status: reopenedclosed

You most certainly can customize the error display, if you'd just go read the docs on how to customize the error display. If, after reading the docs, you still feel there's something missing, please consider proposing changes to the django-dev mailing list instead of endlessly bouncing a ticket open.

comment:5 by Emilian, 17 years ago

Resolution: invalid
Status: closedreopened

I have read the docs, and there is nothing there that deals with this specific problem. Can you point me to specifics?

If you try to display the {{ form.errors }} in a template to provide a place where all the errors are outputted (such as the top of the form), then the output will be as field_name_here followed by the error messages instead of a nicely formatted field label.

After reading through the django-dev mailing list, it is apparent that these kind of changes are to be posted in the Trac system so they can be noted and tracked instead of forgotten.

With all due respect, I want to know if somebody else can look at the ticket and determine its status. It feels that you've approached the suggestion with a certain mindset and are not considering what I am writing.

comment:6 by James Bennett, 17 years ago

Resolution: invalid
Status: reopenedclosed

Right here in the newforms docs are explanations of how errors are displayed and how to customize error display. Please read that. If you feel something is missing, please propose it on django-developers, and do not reopen this ticket unless you can find some consensus for what it suggests.

comment:7 by Jacob, 17 years ago

Guys, both please relax a bit -- no need for the shouting.

Emilian, please don't reopen tickets closed as invalid; the right thing to do in that case is bring the issue up on django-dev. Ticket trackers are a lousy place to have a discussion.

comment:8 by Antti Kaihola, 17 years ago

Note: See TracTickets for help on using tickets.
Back to Top