Opened 17 years ago
Closed 13 years ago
#5992 closed New feature (wontfix)
even more granular error output
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Forms | Version: | dev |
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:
- Allows to define error_class at the class level (in the form class definition)
- Converts errors to the error_class instance when the errors are added to errors dict (in full_clean)
Attachments (1)
Change History (7)
by , 17 years ago
Attachment: | errorlist.patch added |
---|
comment:1 by , 17 years ago
Patch needs improvement: | set |
---|---|
Summary: | [patch] newforms: even more granular error output → even more granular error output |
Triage Stage: | Unreviewed → Design decision needed |
comment:2 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
@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 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:6 by , 13 years ago
Easy pickings: | unset |
---|---|
Resolution: | → wontfix |
Status: | new → 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.
My problem with this is that messages are put into
ErrorList
objects forValidationError
s, and then this would duplicate that work by either turning the errors into a newErrorList
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 thanas_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.