Code

Opened 7 years ago

Closed 7 years ago

Last modified 5 years ago

#3457 closed (fixed)

Allow overriding of error message for each newforms Field type

Reported by: anonymous Owned by: nobody
Component: Forms Version: master
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: UI/UX:

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)

newforms_error_messages.patch (22.8 KB) - added by SmileyChris 7 years ago.
newforms_error_messages.2.patch (22.8 KB) - added by SmileyChris 7 years ago.
fixed EmailField behaviour and made sure current tests still pass (ErrorList.__repr__ now uses force_unicode)
newforms_error_messages.3.patch (40.6 KB) - added by SmileyChris 7 years ago.
with full tests and docs
newforms_error_messages.4.patch (42.7 KB) - added by gwilson 7 years ago.
newforms_error_messages.5.patch (41.2 KB) - added by gwilson 7 years ago.
removed my changes from testcases.py I made during testing

Download all attachments as: .zip

Change History (26)

comment:1 Changed 7 years ago by adrian

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

Sure -- good idea. Could you provide a patch, along with unit tests that confirm this behavior for every field?

comment:2 Changed 7 years ago by adrian

  • Summary changed from newforms needs error_text for fields to Allow overriding of error message for each newforms Field type

comment:3 Changed 7 years ago by Manoj Govindan <egmanoj@…>

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 Changed 7 years ago by Manoj Govindan <egmanoj@…>

  • Cc egmanoj@… added

comment:5 Changed 7 years ago by anonymous

  • Cc jm.bugtracking@… added

comment:6 Changed 7 years ago by anonymous

See also #4063, which proposes a more elegant solution.

comment:7 Changed 7 years ago by Gary Wilson <gary.wilson@…>

  • Triage Stage changed from Accepted to Design decision needed

#4063 marked as a duplicate.

Need to decide what to do with Fields that can raise more than one Error.

comment:8 Changed 7 years ago by ville.anttonen@…

I suggest to use dictionary when multiple errors could occur.

Changed 7 years ago by SmileyChris

comment:9 Changed 7 years ago by SmileyChris

  • Needs documentation set
  • Needs tests set
  • Triage Stage changed from Design decision needed to Accepted

Ok, here you go: a working patch. Just needs documentation and tests...

comment:10 Changed 7 years ago by SmileyChris

  • Has patch set

Changed 7 years ago by SmileyChris

fixed EmailField behaviour and made sure current tests still pass (ErrorList.__repr__ now uses force_unicode)

comment:11 Changed 7 years ago by SmileyChris

For a quick summary of how it works:

  1. each Field instance gets an error_messages dictionary built from the default_error_messages in it's class (and base classes, recursively)
  1. a user can pass in their own error_messages dictionary which .update()s the error_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 Changed 7 years ago by Densetsu no Ero-sennin <densetsu.no.ero.sennin@…>

  • Cc densetsu.no.ero.sennin@… added

Changed 7 years ago by SmileyChris

with full tests and docs

comment:13 Changed 7 years ago by SmileyChris

  • Needs documentation unset
  • Needs tests unset
  • Triage Stage changed from Accepted to Ready for checkin

In reality, noone else was going to do docs or tests. So here they are.

comment:14 Changed 7 years ago by anonymous

  • Cc leo.soto@… added

comment:15 Changed 7 years ago by gwilson

  • Owner changed from nobody to gwilson
  • Status changed from new to assigned

comment:16 Changed 7 years ago by gwilson

  • Patch needs improvement set
  • Triage Stage changed from Ready for checkin to 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.

Changed 7 years ago by gwilson

Changed 7 years ago by gwilson

removed my changes from testcases.py I made during testing

comment:17 Changed 7 years ago by gwilson

  • Owner changed from gwilson to nobody
  • Status changed from assigned to new

comment:18 Changed 7 years ago by niels

  • Cc niels.busch@… added

comment:19 Changed 7 years ago by gwilson

  • Resolution set to fixed
  • Status changed from new to closed

(In [6625]) Fixed #3457 -- Allow overridding of error messages for newforms Fields.

comment:20 Changed 7 years ago by gwilson

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 Changed 5 years ago by niels

  • Cc niels.busch@… removed

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.