Hi Both – Good discussion!
Here are some initial thoughts.
Now that we’ve got template based rendering as well as other improvements such as the addition of as_field_group() I’ve been thinking about what else would ease form rendering. css_classes is clearly one example but there are others too. One other example is the ability to ease rendering of classes on the widget especially when they depend on state. (e.g. something like form-invalid when there are errors), another is to allow a reference to the form from the widget.
There’s different ways to solve these. Template customisation has been suggested as one, and we can of course also add additional API for each of these needs. css_classes is one proposal, here was another. Template tags (such as what’s available in django-widget-tweaks) are also an option – crispy forms also makes use of this approach.
What these API proposals generally have in common is that they are customisations to the BoundField. Django allows custom BoundFields today, but I think they are a little onerous to use. You have to override get_bound_field() for each field in your form.
Maybe we should ease customisation of BoundFields at the field/form/project level. A PR along these lines was opened recently, but has no accepted ticket.
This would allow a general approach to customisation of BoundFields to allow folk to do what they want rather than add a specific API for each use case.