Change History (7)

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.

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.

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.

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.