[Django] #22937: Make the default for Form.label_suffix a setting
Django
-----------------------------+--------------------
Reporter: nealtodd | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 0 | UI/UX: 0
-----------------------------+--------------------
Currently, the default for
[https://docs.djangoproject.com/en/dev/ref/forms/api/#django.forms.Form.label_suffix
Form.label_suffix] (a colon (:) in English) is hardcoded in
[https://github.com/django/django/blob/master/django/forms/forms.py#L122
forms.py].
Although this default can be overridden in individual Form and Field
instantiation, the hardcoding makes it difficult to globally set a
different default label suffix across a whole project. A workaround such
as having a base form that sets the attribute does work, but requires all
the forms in a project to inherit from it rather than just from, e.g.,
forms.Form:
{{{
class BaseForm(forms.Form):
def __init__(self, *args, **kwargs):
kwargs.setdefault('label_suffix', '')
super(BaseForm, self).__init__(*args, **kwargs)
}}}
[https://github.com/nealtodd/django/tree/label_suffix_setting This branch]
pulls the default for Form.label_suffix out of forms.py and into a
`django.conf.settings`.
It includes tests and documentation. All Django tests pass using
`test_sqlite`.
It is backwards compatible as it is included in global settings with a
default of ':'.
A typical use-case, and the reason for submitting this patch, is to use an
empty string for the label suffix. Note in the implementation that there's
special handling for that case because translating an empty string doesn't
result in an empty string (because of the placement of the .po file
version strings):
{{{
>>> from django.utils.translation import ugettext as _
>>> _('')
u'Project-Id-Version: Django\nReport-Msgid-Bugs-To: \nPOT-Creation-Date:
2013-10-09 20:17+0200\nPO-Revision-Date: 2010-05-13 15:35+0200\nLast-
Translator: Django team\nLanguage-Team: English <e...@li.org>\nLanguage: en
\nMIME-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-
Transfer-Encoding: 8bit\n'
}}}
Hope it'll be considered useful enough for a PR.
Regards, Neal
--
Ticket URL: <https://code.djangoproject.com/ticket/22937>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-----------------------------+------------------------------------
Reporter: nealtodd | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* needs_docs: => 0
* needs_better_patch: => 1
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
I foresaw this request when I committed the `label_suffix` feature.
Indeed, if you want to customize all the forms in your project in a
certain way, there's not really a good way to do it. Having a custom
`BaseForm(Form)` class in your project that you inherit all your own forms
from is one option, but this doesn't integrate with reuseable apps. #22383
raises a similar issue about adding some sort toggle for whether forms
should render in HTML 4 or 5. However, I don't think adding a setting is
going to fly. Django is already criticized for its use of global settings
which means many modules can't be used outside of Django (I believe forms
is one of the few that doesn't and this is a good thing we shouldn't
break). If you read the DevelopersMailingList, you'll find something call
"unsettings" which describes the problem in more detail and some possible
solutions.
I'll accept the ticket on basis of the problem, but am going to retitle
the summary to remove the notion that adding a setting is the correct
solution. If you'd like to raise the issue on the mailing list and see if
anyone has ideas to solve this, that could be great.
--
Ticket URL: <https://code.djangoproject.com/ticket/22937#comment:1>
Django
-----------------------------+------------------------------------
Type: New feature | Status: new
Component: Forms | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by russellm):
The same (or similar) request have been made before - #18133, #6877,
#5502, #5129, #4975.
IMHO, The real fix here is template-driven form rendering, not Yet Another
Setting.
--
Ticket URL: <https://code.djangoproject.com/ticket/22937#comment:2>
Django
-----------------------------+------------------------------------
Type: New feature | Status: new
Component: Forms | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by nealtodd):
I seem to have managed not to submit my follow up comment acknowledging
the previous requests, and valid reasons for not wanting Yet Another
Setting. I was coming from the perspective that most of the projects I
work on are bespoke rather than reusable apps where an empty string is the
preferred global label suffix - and it puts a bit of a burden on a multi-
developer codebase to ensure all forms use a custom base class (granted,
not excessive, just a bit of noise in the codebase it'd be nice not to
need).
Nevertheless, you've given perspective on the bigger picture for
maintaining Django that I hadn't given as much appreciation to -
particularly the use of settings preventing modules being used outside.
I'll read up on "unsettings" and ponder other solutions - and I agree that
template-driven form rendering would solve a multitude of issues with the
flexibility of form rendering.
Thanks for the consideration and feedback, much appreciated. I won't be
offended by a WONTFIX!
--
Ticket URL: <https://code.djangoproject.com/ticket/22937#comment:3>
Django
-----------------------------+------------------------------------
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by nealtodd):
* status: new => closed
* resolution: => wontfix
--
Ticket URL: <https://code.djangoproject.com/ticket/22937#comment:4>