#3457 closed (fixed)
Allow overriding of error message for each newforms Field type
Reported by: | anonymous | Owned by: | nobody |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Keywords: | ||
Cc: | egmanoj@…, jm.bugtracking@…, densetsu.no.ero.sennin@…, leo.soto@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Right now, the only field type that allows custom error messages is RegexField. For those of us that cannot display errors next to their respective field (for whatever reason), having 6 "This field is required." messages in a row just confuses users.
I propose adding error_text to the base Field definition. Adding a simple
self.error_text = error_text or u'This field is required.'
The only design decision I see that needs to be made is how to handle fields that have multiple error messages, e.g., the min/max errors on IntegerField. Perhaps arguments would work there, too: max_error_text, min_error_text.
Attachments (5)
Change History (26)
comment:1 by , 18 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 18 years ago
Summary: | newforms needs error_text for fields → Allow overriding of error message for each newforms Field type |
---|
comment:3 by , 18 years ago
I tried out some code changes (and tests) for implementing a patch. One key question I would like to see answered is how this change should affect the behaviour of RegexField and its subclasses, say URLField. The tests indicate that these classes expect two kind of error messages depending on the nature of the error.
Consider the first kind of error message, raised when the value of the field doesn't fit a given pattern.
>>> f = URLField() >>> f.clean('foo') Traceback (most recent call last): ... ValidationError: [u'Enter a valid URL.']
The error message displayed is the one used by URLField to override the default provided by RegexField.
Now consider the second scenario where the field is required but turns up empty.
>>> f.clean('') Traceback (most recent call last): ... ValidationError: [u'This field is required.']
The error raised in this case is different (the default error defined in the base 'Field' class is used)
If a URLField object is created with a custom error_message, should it still fall back to the default message if value turns out to be empty? Likewise how should a CharField object with a custom error_message behave in such a case?
One possible solution would be to insist that custom error messages take precedence and hence will be always used if present. I don't mind this but I can see why others could have problems with this. Another approach would be to "collect" errors applicable to each field and display them together (a la Rails model validation).
The latter implementation would result in something similar to this:
>>> f.clean('') Traceback (most recent call last): ... ValidationError: [u'This field is required.', u'Enter a valid URL.']
comment:4 by , 18 years ago
Cc: | added |
---|
comment:5 by , 18 years ago
Cc: | added |
---|
comment:7 by , 18 years ago
Triage Stage: | Accepted → Design decision needed |
---|
#4063 marked as a duplicate.
Need to decide what to do with Fields that can raise more than one Error.
by , 17 years ago
Attachment: | newforms_error_messages.patch added |
---|
comment:9 by , 17 years ago
Needs documentation: | set |
---|---|
Needs tests: | set |
Triage Stage: | Design decision needed → Accepted |
Ok, here you go: a working patch. Just needs documentation and tests...
comment:10 by , 17 years ago
Has patch: | set |
---|
by , 17 years ago
Attachment: | newforms_error_messages.2.patch added |
---|
fixed EmailField
behaviour and made sure current tests still pass (ErrorList.__repr__
now uses force_unicode
)
comment:11 by , 17 years ago
For a quick summary of how it works:
- each
Field
instance gets anerror_messages
dictionary built from thedefault_error_messages
in it's class (and base classes, recursively)
- a user can pass in their own
error_messages
dictionary which.update()
s theerror_messages
dictionary for that instance
>>> from django.newforms import * >>> d = DecimalField(error_messages={'invalid':'Mr T says, "Enter a valid number, foo!"'}) >>> d.clean('jibberjabber') Traceback (most recent call last): File "<pyshell#72>", line 1, in -toplevel- d.clean('jibberjabber') File "[...]\django\newforms\fields.py", line 237, in clean raise ValidationError(self.error_messages['invalid']) ValidationError: [u'Mr T says, "Enter a valid number, foo!"']
comment:12 by , 17 years ago
Cc: | added |
---|
comment:13 by , 17 years ago
Needs documentation: | unset |
---|---|
Needs tests: | unset |
Triage Stage: | Accepted → Ready for checkin |
In reality, noone else was going to do docs or tests. So here they are.
comment:14 by , 17 years ago
Cc: | added |
---|
comment:15 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:16 by , 17 years ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Ready for checkin → Accepted |
brought patch up to date, but tests still failing for python 2.3 due to non-evaluation of lazy objects when printing out ErrorList.
by , 17 years ago
Attachment: | newforms_error_messages.4.patch added |
---|
by , 17 years ago
Attachment: | newforms_error_messages.5.patch added |
---|
removed my changes from testcases.py I made during testing
comment:17 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:18 by , 17 years ago
Cc: | added |
---|
comment:19 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:20 by , 17 years ago
Sorry that I forgot to mention it in the commit message, but many thanks to SmileyChris
for the bulk of the work done on this patch.
comment:21 by , 16 years ago
Cc: | removed |
---|
Sure -- good idea. Could you provide a patch, along with unit tests that confirm this behavior for every field?