Cannot use custom file input widgets

[Noah-Houghton]

I am working on a project where we want to use different file input widgets for different use cases; obviously we'd like to inherit from the existing Django file inputs to reduce code re-use and get Django's file handling for free. However, we discovered that templates/bootstrap5/field.html explicitly disallows this for file inputs, e.g.

{% if field|is_file %}
  {% include 'bootstrap5/layout/field_file.html' %}
{% elif field|is_select %}
  ...

Our current workaround is to manually copy the contents of Django's FileInput and ClearableFileInput to custom input fields which we can then use to create a custom widget; however, this is clearly not a preferable solution. My questions are:

1. is there a reason to explicitly disallow setting a custom File input?
2. could support be added to override the file field rendering by e.g. using the same crispy_field approach used for other input types?

[smithdc1]

+1 for changes that can ease users customizing widgets and fields.

With the investigation you have done do you have ideas on potential solutions?

Edit:

I was wondering if something like allowing subclasses of FileInput here could be a solution.

https://github.com/django-crispy-forms/django-crispy-forms/blob/main/crispy_forms%2Ftemplatetags%2Fcrispy_forms_field.py#L39

[Noah-Houghton]

@smithdc1 When I was poking around in the source code replacing the line I quoted above with {% crispy_field field %} worked to render my custom widget. I'm not sure what impact this would have on the default rendering behavior for file fields though; I'm also relatively inexperienced with the internal logic of crispy-forms so not sure if there would be deeper implications to this change.

[Noah-Houghton]

I think to preserve backwards-compatibility, it would probably be best to check for some documented flag (e.g. crispy_custom_file_field or some such) on the widget, which would then allow for fairly simple logic -- if the flag is set, just run the crispy_field template tag; if not, use the existing logic.

[smithdc1]

I've set up a demo project for me to understand your issue in more detail.

https://github.com/smithdc1/crispy-bs5-209

This project has a page which contains 3 forms:

• A form with a file field with no customisation, rendered with the crispy |filter.
• A form with a custom widget, rendered with the crispy tag.
• A form with a custom widget and a custom template, rendered with the crispy tag.

Maybe one of these options helps answer your question. If not, could you help me understand what further customisation you are making so I can have a minimal reproduce of your issue?

Thanks!

[gracewhitney]

Thanks for looking into this!

It looks like that demo uses the template option in the Field layout to render the custom template -- the CustomFileWidget you've set up is having no effect on its own. I think if you remove the template attr from the layout Field and add it to the CustomFileWidget, you'll see the described behavior.

This may be a workaround option for the case described, but for all other field/widget types, specifying the template on the widget is sufficient to render that custom widget in a form rendered with {% crispy form %}, without any additional layout changes. It's cumbersome and unintuitive to need to handle this case differently for file fields than for all other custom widgets, and requires adding a custom layout to the form and manually specifying all fields even if you want the rest of the layout to have default behavior. I'm also not sure if this works if the widget logic needs to add additional rendering context -- will that be respected by the layout field rendering logic?

[smithdc1]

I think if you remove the template attr from the layout Field and add it to the CustomFileWidget, you'll see the described behavior.

I see the error now. Thank you for explaining this.

It's cumbersome and unintuitive to need to handle this case differently for file fields than for all other custom widgets,

I'm not sure this is the case for all other widgets? I think this is also the case for radio and multiple check boxes. This line here works in a similar way as for file fields?

crispy-bootstrap5/crispy_bootstrap5/templates/bootstrap5/field.html

Line 22 in a6346ec

{% include 'bootstrap5/layout/radio_checkbox_select.html' %}

Typically, the Field(template=...) approach is the escape hatch for custom behaviour. I do understand though if you don't already have a layout then that's additional work.

Another option is that you could override the provided field_template, see docs. There's a couple of options, you can either set it on the form helper, or customise it more generally by overriding the template. Maybe some additional blocks could be added to the template to the default field.html template make extending from it easier?

[gracewhitney]

Overriding the field template with any of these config options isn't an ideal solution, since we don't want to change the field rendering -- we only want to change the widget rendering. We could copy the template and remove that one carve-out, but then we'd need to re-copy the template to again remove that file carveout any time we want to upgrade to a new version of bootstrap, for example. We really like all the default field layout behavior that this template pack does, but we still want to be able to customize individual widgets without affecting the rest of the field label, help text, errors, etc.

The crispy layouts for these fields are better than the Django default widget templates, and that's great, but we still want to be able to override them. There's not a great way for the code to know if the widget's template is the django default one rather than a custom one, unfortunately, but it would be helpful if we had a way to provide that information so that our custom rendering logic can still override the template pack template. For example, another flag we can set on the widget and which will be checked any time a custom template is included in the field template instead of using the crispy field tag.

It's true, this issue also applies to those other fields. We haven't encountered it there as we haven't found a use case for subclassing those Django widgets with a new template.