[Django] #20000: Allow overriding `label`, `help_text` and `error_messages` for the default fields in `ModelForm`
Django
fields in `ModelForm`
-----------------------------+--------------------
Reporter: loic84 | Owner: loic84
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 `ModelForm` requires to completely redefine fields in order to
customize user-facing strings such as `labels`, `help_texts` and
`error_messages`.
This leads to a lot of boilerplate code to anyone who wants to customize
these, but most importantly it's an error prone process. The bigger the
ModelForm becomes, the more difficult it is to ensure functional parity
between the `Model` fields and the `Form` fields for the critical parts
such as blank/required, default, validators, etc.
One shouldn't be at risk of completely breaking a form functionality in
order to make small cosmetic changes.
It's understood that we have to draw a line somewhere, else we would have
field definitions in the `Meta`, but I believe that line should be drawn
at "anything cosmetic" available through `Meta` overrides, and "anything
functional" through fields overrides. I believe the currently provided
`widgets` lie in between the two, so it's almost surprising that it was
added as a convenience in a first place instead of the purely cosmetic
options.
--
Ticket URL: <https://code.djangoproject.com/ticket/20000>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
Type: New feature | Status: new
Component: Forms | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by loic84):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
https://github.com/loic/django/compare/ticket20000
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:1>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by jezdez):
* status: new => closed
* resolution: => wontfix
Comment:
This has been previously discussed and wontfixed before. Feel free to
raise the issue on the developer list.
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:2>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Comment (by carljm):
FWIW, I think this patch would be a positive improvement. It makes common
customization cases simpler, and avoids the error-prone alternative of
overriding the field entirely and the extra-boilerplate alternative of
overriding `__init__` and patching fields there. I also think the supplied
new customization points are very similar in nature to the existing
`Meta.widgets`, and it's an odd inconsistency to have one but not the
others. What argument is there for `Meta.widgets` that does not apply
equally to labels, help texts, and error messages?
In other words, if you decide to bring it up on django-developers, I am +1
for the change.
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:3>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
Type: New feature | Status: new
Component: Forms | Version: master
Keywords: | Triage Stage: Design
Has patch: 1 | decision needed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by carljm):
* status: closed => new
* resolution: wontfix =>
* stage: Unreviewed => Design decision needed
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:4>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
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
Changes (by jacob):
* stage: Design decision needed => Accepted
Comment:
I agree with Carl.
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:5>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
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: 0
Comment (by loic84):
PR https://github.com/django/django/pull/987
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:6>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
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: 0
Comment (by lrekucki):
Just for the record, this is a duplicate of #17924.
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:7>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
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: 0
Comment (by timo):
I've updated the pull request to merge cleanly and also added the
`labels`, `help_texts`, and `error_messages` arguments to the
`model(form|formset)_factory` functions:
https://github.com/django/django/pull/1251
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:8>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
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: 0
Comment (by jezdez):
I've previously warned that introducing the `widgets` parameter to the
`Meta` class would open up the possibility "to ask for more". I can't
believe Jacob or Carl would become soft in the strict separation of
concern between form class and field.
Since I can't provide an alternative as requirement to veto a feature
request other than "DON'T DO IT!!1!" I'm forced to change to -0. But I
reserve the right to say "I told you so" when a ticket is opened to allow
overriding arbitrary field options in the `Meta` class.
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:9>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
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: 0
Comment (by timo):
An alternative which may mitigate the underlying issue of making simple
customizations on a `ModelForm` without having to redeclare the options
that are generated by the default form:
{{{
FooFormField = MyModel._meta.get_field('foo').formfield() # would probably
need a better API
class MyModelForm(ModelForm):
foo = FooFormField(label='My Foo')
}}}
Alternatively, we could recommend doing customization's in `__init__`, but
it doesn't see like the cleanest solution.
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:10>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
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: 0
Comment (by loic84):
I dislike the FooFormField suggestion, it's very verbose and the intent
(override the label) is not immediately obvious.
Also I can't think of any other places in Django where we use such pattern
so it feels particularly out of place.
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:11>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
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: 0
Comment (by timo):
But it could be a way to override selected options on the the default
`ModelForm` field without having to redeclare all of that field's default
options (i.e. for non-cosmetic changes).
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:12>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
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: 0
Comment (by mrmachine):
As jezdez points out, this opens up the possibility to "ask for me"... I
liked #17924 and I am asking for more :) If we're going to hard code
support for a few special cases, why not just support anything in a clean
and DRY/elegant/flexible way as was suggested before...
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:13>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
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: 0
Comment (by carljm):
I think we should move ahead with this ticket as outlined in the
description.
I might favor the version in #17924 if we were designing the API from
scratch, but the problem with #17924 is that for consistent API it would
imply deprecating Meta.widgets, and I just don't think the benefit of a
"universal" approach is worth a deprecation cycle for already-existing
functionality that's in wide use. (#17924 also carries the minor
disadvantage of requiring a lot more commas, quotes, and curly braces for
simple customizations.) If we have the common cases covered via direct
Meta options, overriding `__init__` is still always an option for the
uncommon cases.
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:14>
Django
fields in `ModelForm`
Reporter: loic84 | Owner: loic84
Type: New feature | Status: closed
Component: Forms | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Changes (by Tim Graham <timograham@…>):
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"9e50833e2293aa2734f14f9873abe4f83d03b8c6"]:
{{{
#!CommitTicketReference repository=""
revision="9e50833e2293aa2734f14f9873abe4f83d03b8c6"
Fixed #20000 -- Allowed ModelForm meta overrides for label, help_text and
error_messages
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/20000#comment:15>