#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 django-updates+unsubscr...@googlegroups.com. 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.