#18237 closed New feature (wontfix)
Custom error messages in ModelForm-s
Reported by: | Karol Sikora | Owned by: | nobody |
---|---|---|---|
Component: | Forms | Version: | 1.4 |
Severity: | Normal | Keywords: | modelform, error messages |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
There should be a simple and dry way to override default error messages for ModelForms. According to #13693 and custom experience error_messages in field definitions does not working. One of solution is implementing something like http://blog.brendel.com/2012/01/django-modelforms-setting-any-field.html, but I definitely think that error_messages from model definition is the best way. Doing this by redefining fields in form breaks IMHO dry rules.
Change History (6)
comment:1 by , 13 years ago
Component: | Uncategorized → Forms |
---|
comment:2 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:3 by , 13 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Defining form field to override error message is, in my opinion, hardly DRY violation. Maybe making field params overridable isn't good choice, but method that You proposed also isn't good. Why getting error messages form error_messages parameter in model definition is bad way? As I know these messages are used in admin, so there is the most intuitive way to set these messages also for model forms through error_messages in model definition. I don't agree with You to close this ticket, maybe it will be useful to get to know other's opinion.
comment:4 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
If you disagree with a core developer who closed a ticket as wontfix, please make your case on the django-developers mailing list, in order to reach a wider audience. Thanks!
comment:5 by , 13 years ago
comment:6 by , 13 years ago
Note that I just reopened #13693, which I believe would address the core use case here, without adding a Meta option.
There is a simple way, subclass the form and override the error message in a new form field. It's hardly a DRY violation if you want to modify the default behavior. The linked blog post proposes making the field params overridable by having more options in the
Meta
class, the worst possible API for form composing IMO. Closing as wontfix.