Code

Opened 6 years ago

Closed 6 years ago

Last modified 6 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: master
Severity: Keywords: errordict
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

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.

Attachments (0)

Change History (8)

comment:1 Changed 6 years ago by Emilian

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 follow-up: Changed 6 years ago by ubernostrum

  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:3 in reply to: ↑ 2 Changed 6 years ago by Emilian

  • Resolution invalid deleted
  • Status changed from closed to reopened

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 Changed 6 years ago by ubernostrum

  • Resolution set to invalid
  • Status changed from reopened to closed

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 Changed 6 years ago by Emilian

  • Resolution invalid deleted
  • Status changed from closed to reopened

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 Changed 6 years ago by ubernostrum

  • Resolution set to invalid
  • Status changed from reopened to closed

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 Changed 6 years ago by jacob

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 Changed 6 years ago by akaihola

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.