[Django] #26234: No way to specify css classes of form fields.
Django
------------------------------+-----------------------
Reporter: willstott101 | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: 1.9
Severity: Normal | Keywords: css forms
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 1 | UI/UX: 0
------------------------------+-----------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26234>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: willstott101 | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: 1.9
Keywords: css forms | Triage Stage: Unreviewed
Has patch: 1 | Easy pickings: 1
UI/UX: 0 |
Changes (by willstott101):
* Attachment "django-forms-css.patch" added.
Django
------------------------------+--------------------------------------
Reporter: willstott101 | Owner: nobody
Type: New feature | Status: new
Component: Forms | Version: 1.9
Keywords: css forms | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
Comment:
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
[http://stackoverflow.com/questions/401025/define-css-class-in-django-
forms ideas on stackoverflow].
--
Ticket URL: <https://code.djangoproject.com/ticket/26234#comment:1>
Django
------------------------------+--------------------------------------
Type: New feature | Status: new
Component: Forms | Version: 1.9
Keywords: css forms | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Comment (by willstott101):
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.
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).
--
Ticket URL: <https://code.djangoproject.com/ticket/26234#comment:2>
Django
------------------------------+--------------------------------------
Type: New feature | Status: new
Component: Forms | Version: 1.9
Keywords: css forms | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Comment (by willstott101):
Replying to [comment:1 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26234#comment:3>
Django
------------------------------+--------------------------------------
Type: New feature | Status: closed
Component: Forms | Version: 1.9
Severity: Normal | Resolution: wontfix
Keywords: css forms | Triage Stage: Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Changes (by timgraham):
* status: new => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26234#comment:4>