#13693: error_messages for fields in Model don't carry over to ModelForm
---------------------------------+------------------------------------------
Reporter: Aleks | Owner: anonymous
Status: closed | Milestone:
Component: Forms | Version: 1.2
Resolution: wontfix | Keywords: error_messages, forms, models
Stage: Unreviewed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
---------------------------------+------------------------------------------
Comment (by Honza_Kral):
Replying to [comment:3 carljm]:
> > Marking this as wontfix since I don't believe this is an issue.
>
> Honza, you certainly know a lot more than I do about model-validation,
but I don't think I agree with the wontfix here. In general my mental
model of ModelForms is that they pull as much information as possible from
the model definition for the form default, to minimize the boilerplate
needed to make a form for that model. Personally, I'd be surprised if I
defined a custom validation error message on a model field and found that
it didn't propagate to the ModelForm by default. It's possible that I'm
missing something important, but I can't think of a case where I wouldn't
want that as the default behavior. Maybe you can explain in a bit more
detail why that's a bad idea? Or else reopen, and I'm willing to put in
some time to work out the test-suite issues and any other problems with
the patch.
My first issue is that it is mildly backwards incompatible (hence the
broken tests) - nothing big but still. The other is that form validation
and model validation serve different purposes and may work differently,
requiring differently phrased error messages, for example the model
DateTimeField accepts different date formats than the same field on the
form level and the error message is worded differently because of that.
For me it's the question of locality - I define some validation on the
model level and expect to use the model's error messages and similarly
with forms. Otherwise I think it cold be confusing and we would need to
keep the logic and message formats synchronized.
Another thing is the codes of the messages - half of them are called
'invalid' which is very generic and thus have a high probability of name
clashes - I could define my validation on the model level, use 'invalid'
for a code and then try to override the message only to see the message on
completely unrelated validation result.
I completely agree that the idea is good and these are minor issues that
can be fixed (although by introducing minor backwards incompatibilities)
but until they are, this ticket doesn't bring enough positive to ignore
them. So I am -1 on this until these issues are addressed and resolved
which I don't think is the priority ATM.
Sorry for not providing more detailed explanation earlier, hope this
helps.
--
Ticket URL: <http://code.djangoproject.com/ticket/13693#comment:4>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
