Add `css_classes` parameter to Form.as_*() methods

[Will Stott]

Currently the as_p as_table and as_ul functions on forms have no customisation for the class of fields. Proposing adding the ability to pass css classes through. Personally this will be useful for semantic-ui integration, which expects the field's container to have the 'field' class to render properly.

[Tim Graham]

I'm concerned that adding this could open a can worms of customization parameters for the as_*() methods which I think are really meant as simple shortcuts when very little customization is needed .

I'm inclined to say you should do this with a Python mixin:

class FormFieldClassesMixin(object):
    def __init__(self, *args, **kwargs):
        super(FormFieldClassesMixin, self).__init__(*args, **kwargs)
        for field_name, field in self.fields.items():
            field.widget.attrs['class'] = 'someClass'

or in your own custom template tag. See also ​ideas on stackoverflow.

[Will Stott]

Replying to timgraham:

I'm concerned that adding this could open a can worms of customization parameters for the as_*() methods which I think are really meant as simple shortcuts when very little customization is needed .

I understand why you're concerned. I would justify this by saying that the patch only modifies the actual tag specified in the method name. As the method is already a direct reference to that html tag, any customisation would be logically kept to the tag which that function adds (surely never more than attrs={}).

I also don't see many situations where additional parameters would get passed into the Field.css_classes method. As it would surely be only called in:

• a template (where you would just class="{{field.css_classes}} myclass" anyway)
• this Form._html_output method
• or something very similar and unnecessary to write.

I just feel the .as_* methods are almost useless without some customisation. And it feels natural for me to do form.as_p('large') or the like with that method.

I'm inclined to say you should do this with a Python mixin:

Your particular snippet adds classes to the widget, not the form container (i.e. also encompassing the <label>).

But I get where you're coming from. And I've used a more granual(?) form template to get around this, which was simpler than I expected (but brings up the "what's the point" in the methods if they can't be adjusted argument again).

[Will Stott]

Replying to timgraham:

BTW this is my first time on trac, that comment above wasn't a reply to you at first, but I edited it to be. IDK if the notification would be sent on an edit. So I'm making this reply too.

[Tim Graham]

Let's reopen this if you can get consensus on the DevelopersMailingList to do it. I'm still not certain promoting more use of these methods is a good idea.

Maybe template-based widget rendering (#15667) will help for your use case.