#18506: (Model)Forms localize=True violates DRY
-------------------------------+--------------------
Reporter: vanschelven | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.4
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
As it is now one cannot make localized !ModelForms without violating DRY.
Developers w/o the desire for localized data in their application can
simply take a model and then create a modelform in three lines and an
admin interface in even less. However, a developer that wants localization
to work in the admin/their modelforms needs to set the attribute
localize=True for each single field that they want localized. This breaks
DRY as there is both repetition of the "localize=True" and it also
introduces new repetition between models & their forms.
I understand that the decision to make localize=False the default was both
deliberate and probably the correct one, as Russel explains here:
http://groups.google.com/group/django-
developers/browse_thread/thread/01096cd968bf276a/9ad982e939f1284f
However, a couple of notes:
* I think the case Russel mentions is the exception, not the rule.
"Usually" a number is just a number, not a year. Postal codes and phone
numbers are often not numbers at all.
* We (Django) have made the opposite decision for template rendering:
Indicating USE_L10N in settings makes localized rendering the default
throughout the application, and the developer is left to find the
exceptions and note them whenever they occur. This is inconsistent with
the way we deal with forms (and has the usual drawbacks of inconsistency,
such as the confusion of the OP in the email above).
My suggested solution would be to add an attribute to !ModelFields.
We already have a number of cases in which attributes of models' fields
are propagated to your modelforms. blank => not required, verbose_name =>
label and help_text => help_text spring to mind.
I'd say name this attribute "localize" and default it to True (since
that's the most common case). But this will introduce backwards breakage,
so I can also imagine simply keeping it False as a default. That would at
least get rid of the violation of DRY mentioned above. Alternatively the
default value of this attribute could be settings.USE_L10N.
Once we have localize=!True/False on modelfields, we could even envision
using that value in template output as well, i.e. years will automatically
be recognized as such and we no longer need to explicitly mark them as
non-localized each time they're used in a template. But maybe that's
ground for another ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/18506>
Django <https://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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
