Opened 7 years ago

Closed 4 years ago

#5992 closed New feature (wontfix)

even more granular error output

Reported by: Max Derkachev <mderk@…> Owned by: nobody
Component: Forms Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

The custom ErrorList supplied to a Form object is not respected when an individual field errors are displayed, e.g {{ form.my_field.errors }}

The patch solves two issues:

  1. Allows to define error_class at the class level (in the form class definition)
  1. Converts errors to the error_class instance when the errors are added to errors dict (in full_clean)

Attachments (1)

errorlist.patch (1.8 KB) - added by Max Derkachev <mderk@…> 7 years ago.

Download all attachments as: .zip

Change History (7)

Changed 7 years ago by Max Derkachev <mderk@…>

comment:1 Changed 7 years ago by gwilson

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement set
  • Summary changed from [patch] newforms: even more granular error output to even more granular error output
  • Triage Stage changed from Unreviewed to Design decision needed

My problem with this is that messages are put into ErrorList objects for ValidationErrors, and then this would duplicate that work by either turning the errors into a new ErrorList or some custom error class instance. I think this needs some more ironing out. Also curious, what are your motivations for using a custom error class? To use a different output method other than as_ul?

I am currently playing with extracting the output formatting methods from the BaseForm class. That work might be able to help the situation here too.

comment:2 Changed 7 years ago by Max Derkachev <mderk@…>

I thought about that duplicate work. The problem is that ValidationError itself does store errors list in ErrorList instance. Since there are no sensible way to tell it the error list class, my thought was that it should not convert error messages at all - the full_clean method should, and that would eliminate double convertion.

And for the custom errorlist class. Yes, I need different output method. Moreover, the standard method for this (custom errols list class) is provided by the API. And the fact that custom class is used when the whole form is dumped via as_ul or something, and is not respected when an individual error output is inserted into a template, looks like a bug to me.

comment:3 Changed 7 years ago by jacob

I can't really figure out what this patch is supposed to do. Can you clarify why you can't just change the display of output in the template?

comment:4 Changed 7 years ago by Max Derkachev <mderk@…>

@jacob

I can't change the output of ErrorList in template.
When I write {{ form.errors.field_name }}, the ErrorList renderer comes, and its output might be not the thing I'd like to see. E.g., if I want the errors shown in divs, not in ul/li. Custom error_class does not help in this case (it works at form.as_ul and friends level only). The patch fixes this issue - the custom error_list is respected any time the errors are rendered.

comment:5 Changed 4 years ago by gabrielhurley

  • Severity set to Normal
  • Type set to New feature

comment:6 Changed 4 years ago by carljm

  • Easy pickings unset
  • Resolution set to wontfix
  • Status changed from new to closed
  • UI/UX unset

Modifying error display via a custom ErrorList class is only necessary if you are rendering your form with e.g. {{ form.as_p }}. Those methods are only intended for quick prototyping - if you really need to control your display markup, you should render your form in templates. If you do that, and you're at the point where you're writing {{ form.field_name.errors }} in your template, you can instead write {% for error in form.field_name.errors %}...{% endfor %} and display the errors however you want, bypassing the built-in ErrorList rendering entirely. And that can be wrapped up into an {% include %} and made just as concise.

Closing this wontfix, the preferred approach is to put as much markup as possible in templates rather than Python code.

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