Form customization

[Alex Scott]

Hi all,

Are there any current plans or developments to allow better customization of forms?  I've browsed several old Stack Overflow, django-users and Django ticket requests and it seems common enough to want to say, add a class to every form field or field label, or change the label suffix from ":" to "".

The current "solutions" seem hacky and non-DRY, usually requiring custom code for every form used in a site.

Would it be a terrible idea to allow these to be set in settings or in a base form that gets inherited by everything else?

Thanks,

Alex

[Confi Yobo]

I kind of support what you are saying Alex Scott, I think the form should be simplified at currently it takes a lot of time to setup a simple contact form.

My suggestion is that upon creation of every form there should be properties and methods to allows you to customize the form. Simplifying the form will eliminate the need for using third party library like DJANGO-CRISPY-FORMS.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMiVppbh%2BOAWa6z0k0m2uQj0ZrguCAzgz3tt3yhWa6_FjMO_ow%40mail.gmail.com.

[Carlton Gibson]

Hi Alex

Can you be more specific please? 

On Sunday, 6 October 2019 01:11:52 UTC+2, Alex Scott wrote:

Would it be a terrible idea to allow these to be set in settings or in a base form that gets inherited by everything else?

 Without seeing exactly the problems you have in mind, it's hard to say... — By using a base form class in your project, overriding templates, and/or default field mappings, I would imagine everything you need is already possible. 

(Quite likely there's room for a deeper How To on advanced form customisation in the docs though.)

Kind Regards,

Carlton

[Alex Scott]

Yeah it very well might be the case that I'm missing something or that some additional documentation is all we need (I'm not new to Django but far from an expert and took a long hiatus).

The first example is the label suffix, which seems to be given a hard coded default here.  I think there are many ways to override / deal with this, but if you're using a mix of Forms and ModelForms and want to still enjoy much of the magic of Django, what's the recommended solution to, say, remove that colon in all your forms?  Seems like you can... (1) Just manually write the labels yourself in the template (2) Create new base form classes that extend Form/ModelForm and remove the colon, and then make sure all your forms use those (3) Manually deal with this in form instantiation or via get_form() or some other method (4) Maybe more?

As a lay user, this all seems pretty complex to change something so seemingly simple and there doesn't seem to be a "recommended" way.

Another example is say, adding a class to every input field because you want to style them appropriately.  Solutions to this exist, but they again seem far from "plug n play", even when I'm guessing a majority of users want to do this (since if you're using Bootstrap, Foundation, Bulma, etc it's needed).

I have a few more examples but will stop there.  Let me know what you think.

[Jacob Rief]

With Django-1.10 we got the ability to override form fields with our own templates, however the form structure is still hard-coded.

Examples are BaseForm.as_table(), BaseForm.as_ul() and BaseForm.as_p()

For instance, the popular Bootstrap framework requires a <div class="form-group"> wrapped around each field, so I created a mixin class which I add to my Django Forms.

There I added a method named as_div() which renders all my fields in a Bootstrap-ish way. This of course is not very intuitive.

My question here is, couldn't we make the arguments normal_row, error_row, row_ender and help_text_html, which are passed to method self._html_output, more configurable?

Those arguments could maybe be replaced by some special templatetags and then consumed by a template responsible to render the form structure in a similar way as the as_...() methods mentioned before.

[1337 Shadow Hacker]

Try tri.forms maybe

The main problem IMHO is that rendering is stuck in a template system, rather than components that could leverage the decorator pattern as it's known to be better for UI programing (cf. GoF, React & friends success)

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

[Carlton Gibson]

HI Alex, 

For label_suffix, I'd say a base form class for your project is exactly the way to go. 

You can set CSS classes at the field level[0]

... — I suspect the API is there, but maybe reviewing the guide[1] for where it's lacking might be good. 

There are also third-party options, such as Crispy Forms, which can give more options. 

[0]: https://docs.djangoproject.com/en/2.2/ref/forms/api#django.forms.BoundField.css_classes

[1]: https://docs.djangoproject.com/en/2.2/ref/forms/index

[2]: https://django-crispy-forms.readthedocs.io/en/latest/layouts.html

Hi Jacob — Possibly. Sounds like a moderate change... — what would it look like? — proof of concept. (As ever... :) 

Have a good weekend all. 

Kind Regards. 

Carlton 

[Carlton Gibson]

A better link for the CSS class issue is this one 

https://docs.djangoproject.com/en/2.2/ref/forms/widgets/

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d4412f19-1a36-4097-870b-ee71be9cddc1%40googlegroups.com.

[Jacob Rief]

Hi Jacob — Possibly. Sounds like a moderate change... — what would it look like? — proof of concept. (As ever... :) 

Something similar such as the templatetag render_form from django-restframework, but instead of using a serializer, we'd use a form object.

crispy-forms uses a filter to achieve a similar goal, but somehow I prefer the DRF approach.