[Django] #35191: Allow form renderer to use custom template for label tag
Django
-------------------------------------+-------------------------------------
Reporter: oxan | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Forms | Version: 5.0
Severity: Normal | Keywords: forms render
Triage Stage: | template
Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-------------------------------------+-------------------------------------
Currently, a form renderer can't easily change the template used by the
`BoundField.label_tag()` method: `template_name_label` can be set on the
form, but there exists no `label_template_name` on the `FormRenderer` that
it fallbacks to.
This is problematic if e.g. CSS classes need to be set on the form labels.
Writing out the `<label>` tag in the template instead of calling
`label_tag()` is also not an option, as `label_tag()` does somewhat
complex processing to ensure the correct id (and label) are used.
--
Ticket URL: <https://code.djangoproject.com/ticket/35191>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: | Status: assigned
Cleanup/optimization |
Component: Forms | Version: 5.0
Keywords: forms render | Triage Stage:
template | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => Almaz
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/35191#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner: Almaz
Component: Forms | Version: 5.0
Severity: Normal | Resolution: wontfix
Keywords: forms render | Triage Stage:
template | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):
* cc: David Smith (added)
* status: assigned => closed
* resolution: => wontfix
* easy: 1 => 0
* type: Cleanup/optimization => New feature
Comment:
I don't think a new attribute is needed. You can always
[https://docs.djangoproject.com/en/5.0/ref/forms/renderers/#overriding-
built-in-form-templates override the default template] as any other
template in your project.
--
Ticket URL: <https://code.djangoproject.com/ticket/35191#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner: Almaz
Type: New feature | Status: closed
Component: Forms | Version: 5.0
Severity: Normal | Resolution: wontfix
Keywords: forms render | Triage Stage:
template | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
The problem with overriding the default template is that it's global to
the project, while form renderers are local to the form. This is useful
e.g. if there multiple different form layouts are used within a project,
or when incrementally transitioning between design systems. There's also
the matter of consistency: the form, formset and field templates can
already be changed by the renderer, why not the label? After all, the
default template for those could also be globally overridden.
--
Ticket URL: <https://code.djangoproject.com/ticket/35191#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner: Almaz
Type: New feature | Status: closed
Component: Forms | Version: 5.0
Severity: Normal | Resolution: wontfix
Keywords: forms render | Triage Stage:
template | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
> There's also the matter of consistency: the form, formset and field
templates can already be changed by the renderer, why not the label?
There are also many templates that the renderer cannot override, such as
`ErrorDict` or `ErrorList` templates. There are also many templates that
the renderer cannot override, such as `ErrorDict` or `ErrorList`
templates. Adding a new customization option is always a bit controversial
(we already have many of them).
--
Ticket URL: <https://code.djangoproject.com/ticket/35191#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: Oxan van Leeuwen | Owner: Almaz
Type: New feature | Status: closed
Component: Forms | Version: 5.0
Severity: Normal | Resolution: wontfix
Keywords: forms render | Triage Stage:
template | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
I agree there are more templates that the renderer can't override, but in
practice those are less of a problem, as it's easy to just not use them in
your form and field templates. For example `ErrorDict` and `ErrorList` are
thin wrappers around `dict` and `list` respectively, and you can iterate
over those directly in the field template to generate an error list in
whatever style you want. That's not the case for the label template, as
`BoundField.label_tag()` contains (among other things) somewhat complex
logic to generate the value for the `for` attribute that can't easily be
replicated in a template. Furthermore, even if you do replicate it, I'd be
worried about that logic being considered an implementation detail and
changing in a future version of Django.
What would also work is to extract the logic that generates the id and
contents from `label_tag()` out into separate methods (or properties) of
`BoundField`, which can then be used directly in the field template.
The wider context here (and also behind #35192) is that I'm trying to
implement something that renders forms in a way that's usable with
existing frontend frameworks (such as Bootstrap or Tailwind). Current
attempts at this (such as [https://github.com/django-crispy-forms/django-
crispy-forms django-crispy-forms] or [https://github.com/zostera/django-
bootstrap5 django-bootstrap5]) all render using a custom template tag,
whose implementation pokes around in the internals of the forms component.
In my experience those always have hardcoded special casing and can't
support the full feature set and extensibility of the forms component.
It'd be great if something like that could be implemented in plain Django,
working along with instead of around the forms component. Form renderers
seem like the logical extension point for such an implementation, and
they're nearly there, but at the moment they are a bit too inflexible to
cleanly allow all necessary customization.
--
Ticket URL: <https://code.djangoproject.com/ticket/35191#comment:5>