(Model)Forms localize=True violates DRY

[Klaas van Schelven]

Hi all,

I've created a ticket, but have always understood that calling
attention to tickets should be done separately on the Django-
developers mailinglist, so allow me to copy/paste a bit:

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.


regards,
Klaas van Schelven

[Karen Tracey]

On Fri, Jun 22, 2012 at 7:23 AM, Klaas van Schelven <klaasvan...@gmail.com> wrote:

I've created a ticket, but have always understood that calling
attention to tickets should be done separately on the Django-
developers mailinglist

It's not necessary nor encouraged to call attention to newly-opened tickets on the -developers list. People are asked to post to the list in preference to "contesting" a resolution the don't agree with (e.g. wontfix). Newly-opened tickets on the other hand don't need to be announced on the list, plenty of people monitor the flow of incoming tickets.

Karen

[Serge G. Spaolonzi]

I have opened a ticked for this same issue, it was rejected because the core team didn't liked the idea of including FormField options in ModelField. Decision i think was correct, I wasnt aware the other FormFields options in ModelFields like help_text were there for historical reasons.

https://github.com/cobalys/django/blob/ticket_18471/django/db/models/fields/__init__.py

If this is not the correct way to do it, we need to find another way to do it respecting the DRY principle. 

imao the ModelFields must localize according to settings.USE_L10N, then if it is specified in the option localize as false that field must not localize.

From the official Django Documentation:

USE_L10N

Default: False

A boolean that specifies if localized formatting of data will be enabled by default or not. If this is set to True, e.g. Django will display numbers and dates using the format of the current locale.

As I understand USE_L10N sets the default behavior application wise for the localization.

Regards

Serge G. Spaolonzi

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Klaas van Schelven]

I'll just add my 2 cents as partial copy/paste from the (now closed)
ticket page:

I agree w/ Serge that USE_L10N should be the default value for
localize.

* 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 but a string.

* 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.


* If blank/help_text/verbose_name are considered undesirable elements
of Model Fields I'd love to know what the new canonical pattern for
DRY between models and corresponding forms is. I _do_ think there is
value in not repeating yourself between forms & models.

On Jun 23, 2:22 am, "Serge G. Spaolonzi" <se...@cobalys.com> wrote:
> I have opened a ticked for this same issue, it was rejected because the
> core team didn't liked the idea of including FormField options in
> ModelField. Decision i think was correct, I wasnt aware the other
> FormFields options in ModelFields like help_text were there for historical

> reasons.https://github.com/cobalys/django/blob/ticket_18471/django/db/models/...