This is more or less the idea behind 
https://code.djangoproject.com/ticket/20000 except that the custom 
error_messages would be defined in ModelForm rather than Model. In my opinion, 
Model is a terrible place to define user-facing strings such as help_text or 
error_messages, at best useful to supply default values.

>From a quick glance at the code, we might need some special handling to 
>override the error_messages defined in model fields. I would tackle that if 
>#20000 were to be accepted.

I'll write more thoroughly about #20000 once the discussion about Bruno's 
proposal (ref. #12915) has settled.

-- 
Loic

On Mar 11, 2013, at 8:50 PM, Nicolas Diaz Aragon <[email protected]> 
wrote:

> If the 'error_messages' attribute were also included, then there'd be just 
> one place to define all your error messages: the model. This makes cleaner 
> code, because you know there's only one way to look for error messages.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to