#35191: Allow form renderer to use custom template for label tag
-------------------------------------+-------------------------------------
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
-------------------------------------+-------------------------------------
Comment (by Oxan van Leeuwen):
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>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018da79ae245-a74138cd-e4aa-4266-85ff-2e94030fd9a6-000000%40eu-central-1.amazonses.com.
