Allow Widgets templates to be specified in a FormRenderer class

[nanorepublica]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Optionally allow Widget templates to be specified on a custom FormRenderer class. For example:

class MyFormRenderer(TemplatesSetting):
    form_template_name = "forms/my_form.html"
    field_template_name = "forms/my_field.html"
    # This is new - specific widget template
    select_template_name = "forms/my_widget.html#select"

Problem

We currently have the FormRenderer API which allows customisation of form rendering a variety of levels of specificity (settings, form class, form instance) via the following templates:

form_template_name = "django/forms/div.html"
formset_template_name = "django/forms/formsets/div.html"
field_template_name = "django/forms/field.html"

Currently to override Widgets at a global level, requires monkey-patching the template_name class attribute which then means there are possible clashes and bugs between the user facing styles and admin styles.

Request or proposal

proposal

Additional Details

No response

Implementation Suggestions

Looking at the base Widget class it has two methods that deal with rendering. render and _render

I would propose adding a get_template_name method instead of calling self.template_name directly in this method, which would take a renderer argument. Off the top of my head something like this:

class Widget:
    
    def get_template_name(self, renderer, template_name):
          renderer_widget_attr_name = f"{self.__class__.__name__}_template_name"
          renderer_template_name = getattr(renderer, renderer_widget_attr_name, None)
          if renderer_template_name:
               return renderer_template_name
          return template_name
   
    def _render(self, template_name, context, renderer=None):
        if renderer is None:
            renderer = get_default_renderer()
        template_name = self.get_template_name(renderer, template_name)
        return mark_safe(renderer.render(template_name, context))

Perhaps there is a bit of a refactor of render and _render, but that is not necessary.

[github-actions]

Thank you nanorepublica for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[codingjoe]

Sorry, @nanorepublica, for challenging this proposal. Having worked on the template-based form rendering, I have a somewhat good understanding of the current implementation.

… and it's already pretty complex, while the problem you are describing seems somewhat peculiar.
Having template names per instance (based on a related object) will make debugging form rendering harder, with the increased amount of side effects. To my best knowledge, it would also be unprecedented to have a template name determined based on an instance, not a class.

With the additional runtime and instance dependency, this architecture also opens the door for injection vectors.

My suggested solution for this and many other issues would be inheritance. Alternatively, you can always override template loading; in fact, for the use case you are describing, this would be my preferred solution. It also wouldn't require adjustments to the current Django API.

[nanorepublica]

@codingjoe I'm not suggesting template names per instance (sorry if my quick code examples were not clear and perhaps confused matters!).

I am simply proposing that the FormRenderer class be extended to allow the specification of optional widget templates as per the existing renderer class is used for the 3 templates for form, formset and field. To my mind extending the class to handle widgets is a logical next step.

[codingjoe]

@nanorepublica, thanks for the clarification. In that case, might I suggest following the TemplateView implementation and simply using multiple names from specific to generic?
In that case, you would only need to implement a more specific template w/o the need for a custom renderer.

[nanorepublica]

That's certainly possible, I was currently following the existing API for FormRenderer as it seemed a natural place to extend it, but I'm open to other implementations that make sense.