Re: Form customization

[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.

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7cfb3d9a-e2f3-4da1-b2f3-b57f667a8875%40googlegroups.com.

Re: Form customization

[Carlton Gibson]

A better link for the CSS class issue is this one

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


On Fri, 11 Oct 2019 at 20:54, Carlton Gibson 
wrote:

> 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
>
> On Thursday, 10 October 2019 22:18:03 UTC+2, Jacob Rief wrote:
>>
>> 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 > 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.
>>
> --
> 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-developers+unsubscr...@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
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyRO0D2a-Oeo_rrigz8CjywXon8852jsFTbwU_-UUx2V8g%40mail.gmail.com.

Re: Form customization

[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 

On Thursday, 10 October 2019 22:18:03 UTC+2, Jacob Rief wrote:
>
> 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  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.
>

-- 
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-developers+unsubscr...@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.

Re: Form customization

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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 ‐‐‐
Le dimanche 6 octobre 2019 01:11, Alex Scott  a écrit :

> 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
>
> --
> 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-developers+unsubscr...@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](https://groups.google.com/d/msgid/django-developers/CAMiVppbh%2BOAWa6z0k0m2uQj0ZrguCAzgz3tt3yhWa6_FjMO_ow%40mail.gmail.com?utm_medium=email&utm_source=footer).

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/qBTxFiY0cYK-jSS7a21kO2PZRvcMP1IQ1nwVLpYd5KwThgQPDuGhexO_OzV0MrTtuwd8ZnEpnp6cMnpMb4rSyMzNeHvrb3IUDAUOV7n_bz4%3D%40protonmail.com.

Re: Form customization

[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  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.

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6eb291eb-91f9-4af0-9cd2-ae3fddc5ae4d%40googlegroups.com.

Re: Form customization

[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.

On Tuesday, October 8, 2019 at 12:53:42 AM UTC-7, Carlton Gibson wrote:
>
> 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
>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/718e0ea1-5375-4c81-b0d2-5a2b6b742685%40googlegroups.com.

Re: Form customization

[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

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/471ea89a-9647-44ff-8866-1c663a3d5f61%40googlegroups.com.

Re: Form customization

[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
.

On Sun, Oct 6, 2019 at 12:11 AM Alex Scott  wrote:

> 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
>
> --
> 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-developers+unsubscr...@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
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAD9uRzdagVtR-VZA9TqweCHyk0uPujAnJYkELNiS-_0zrGDdDw%40mail.gmail.com.