Opened 10 years ago
Closed 9 years ago
#22937 closed New feature (wontfix)
Allow configuring Form defaults (like label_suffix) on a per-project basis
Reported by: | Neal Todd | Owned by: | nobody |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Currently, the default for Form.label_suffix (a colon (:) in English) is hardcoded in 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)
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 <en@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
Change History (4)
comment:1 by , 10 years ago
Patch needs improvement: | set |
---|---|
Summary: | Make the default for Form.label_suffix a setting → Allow configuring Form defaults (like label_suffix) on a per-project basis |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 10 years ago
comment:3 by , 10 years ago
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!
comment:4 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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 customBaseForm(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.