Allow usage of widgets in generic class-based views?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Allow usage of widgets in generic class-based views?

Dan F

This ticket has a patch to pass through the "widgets" argument for generic class-based views.

It was closed with "won't fix" with this comment: "I don't think the possibility of saving a few lines of user code justifies the complexity of reimplementing the parameters to modelform_factory() as CBV parameters and methods."

I don't understand. The patch was quite small (doesn't seem complex), and it could give everyone the ability to overload widgets.

Aside from just saving lines of code, it also would act more as expected. I tried using "widgets" before seeing that it didn't work. Also, it would support not making a new form class where every field just has to be copied (useless boilerplate).

Can you accept the patch?

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/781e9f85-c278-46f7-b712-bf49842a9259%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Allow usage of widgets in generic class-based views?

Tim Graham-2
What I meant is that modelform_factory() also has these parameters:

localized_fields is a list of names of fields which should be localized.

labels is a dictionary of model field names mapped to a label.

help_texts is a dictionary of model field names mapped to a help text.

error_messages is a dictionary of model field names mapped to a dictionary of error messages.

field_classes is a dictionary of model field names mapped to a form field class.

If we accept the patch for widgets, then are we headed down the road of adding support for the rest of those arguments? Customizing a form directly rather than indirectly via the view seems like better design to me. It doesn't require adding features to ModelFormMixin as they are added to ModelForm.

On Tuesday, December 4, 2018 at 4:57:40 PM UTC-5, Dan F wrote:
<a href="https://code.djangoproject.com/ticket/24589" style="color:rgb(17,85,204)" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F24589\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGduZO3rKB-6F7jwo8_MWU_Z51c-g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F24589\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGduZO3rKB-6F7jwo8_MWU_Z51c-g&#39;;return true;">https://code.djangoproject.com/ticket/24589

This ticket has a patch to pass through the "widgets" argument for generic class-based views.

It was closed with "won't fix" with this comment: "I don't think the possibility of saving a few lines of user code justifies the complexity of reimplementing the parameters to modelform_factory() as CBV parameters and methods."

I don't understand. The patch was quite small (doesn't seem complex), and it could give everyone the ability to overload widgets.

Aside from just saving lines of code, it also would act more as expected. I tried using "widgets" before seeing that it didn't work. Also, it would support not making a new form class where every field just has to be copied (useless boilerplate).

Can you accept the patch?

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3c990dcb-7753-4888-860f-92572f8895ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Allow usage of widgets in generic class-based views?

Simon Charette
I agree with Tim that this is a slippery slope.

Maybe that adding a ModelFormMixin.get_form_class_options() that returns a
{'fields': self.fields} dict by default and is passed to modelform_factory(**kwargs)
in get_form_class() would be a good compromise?

Best,
Simon

Le mardi 4 décembre 2018 17:28:39 UTC-5, Tim Graham a écrit :
What I meant is that modelform_factory() also has these parameters:

localized_fields is a list of names of fields which should be localized.

labels is a dictionary of model field names mapped to a label.

help_texts is a dictionary of model field names mapped to a help text.

error_messages is a dictionary of model field names mapped to a dictionary of error messages.

field_classes is a dictionary of model field names mapped to a form field class.

If we accept the patch for widgets, then are we headed down the road of adding support for the rest of those arguments? Customizing a form directly rather than indirectly via the view seems like better design to me. It doesn't require adding features to ModelFormMixin as they are added to ModelForm.

On Tuesday, December 4, 2018 at 4:57:40 PM UTC-5, Dan F wrote:
<a href="https://code.djangoproject.com/ticket/24589" style="color:rgb(17,85,204)" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F24589\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGduZO3rKB-6F7jwo8_MWU_Z51c-g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F24589\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGduZO3rKB-6F7jwo8_MWU_Z51c-g&#39;;return true;">https://code.djangoproject.com/ticket/24589

This ticket has a patch to pass through the "widgets" argument for generic class-based views.

It was closed with "won't fix" with this comment: "I don't think the possibility of saving a few lines of user code justifies the complexity of reimplementing the parameters to modelform_factory() as CBV parameters and methods."

I don't understand. The patch was quite small (doesn't seem complex), and it could give everyone the ability to overload widgets.

Aside from just saving lines of code, it also would act more as expected. I tried using "widgets" before seeing that it didn't work. Also, it would support not making a new form class where every field just has to be copied (useless boilerplate).

Can you accept the patch?

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0281164b-9bf7-485f-83ad-c0301630c91a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Allow usage of widgets in generic class-based views?

Carlton Gibson-3
I'd be pretty sceptical about any extra API here. Even an extra hook seems a bit much. 

def get_form_class(self):
    base_form
= super().get_form_class()
   
return modelform_factory(self.model, base_form, widgets=...)


Job done, no? 

(This assuming that "Just declare your form class normally" isn't good advice in context.) 

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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/457c3a50-a2a1-450c-be1b-c3a95405392d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Allow usage of widgets in generic class-based views?

Dan F
In reply to this post by Simon Charette
Ah, I see.

It looks like I can use modelform_factory. So:
class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
model = models.Patient
fields = ['name', 'caregiver_name', 'sex', 'birth_date',
'residence', 'country']
becomes
from django.forms.models import modelform_factory

_patient_create_form = modelform_factory(
models.Patient,
fields=['name', 'caregiver_name', 'sex', 'birth_date',
'residence', 'country'])

class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
form_class = _patient_create_form
template_name = 'healthdbapp/patient_form.html'
and then I can add the widgets:

from django.forms import HiddenInput

from django.forms.models import modelform_factory

_patient_create_form = modelform_factory(
models.Patient,
fields=['name', 'caregiver_name', 'sex', 'birth_date',
'residence', 'country'],
widgets={'country': HiddenInput()})

class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
form_class = _patient_create_form
template_name = 'healthdbapp/patient_form.html'

Works for me.

On Tue, Dec 4, 2018 at 5:04 PM charettes <[hidden email]> wrote:
I agree with Tim that this is a slippery slope.

Maybe that adding a ModelFormMixin.get_form_class_options() that returns a
{'fields': self.fields} dict by default and is passed to modelform_factory(**kwargs)
in get_form_class() would be a good compromise?

Best,
Simon

On Tuesday, December 4, 2018 17:28:39 UTC-5, Tim Graham wrote:
What I meant is that modelform_factory() also has these parameters:

localized_fields is a list of names of fields which should be localized.

labels is a dictionary of model field names mapped to a label.

help_texts is a dictionary of model field names mapped to a help text.

error_messages is a dictionary of model field names mapped to a dictionary of error messages.

field_classes is a dictionary of model field names mapped to a form field class.

If we accept the patch for widgets, then are we headed down the road of adding support for the rest of those arguments? Customizing a form directly rather than indirectly via the view seems like better design to me. It doesn't require adding features to ModelFormMixin as they are added to ModelForm.

On Tuesday, December 4, 2018 at 4:57:40 PM UTC-5, Dan F wrote:

This ticket has a patch to pass through the "widgets" argument for generic class-based views.

It was closed with "won't fix" with this comment: "I don't think the possibility of saving a few lines of user code justifies the complexity of reimplementing the parameters to modelform_factory() as CBV parameters and methods."

I don't understand. The patch was quite small (doesn't seem complex), and it could give everyone the ability to overload widgets.

Aside from just saving lines of code, it also would act more as expected. I tried using "widgets" before seeing that it didn't work. Also, it would support not making a new form class where every field just has to be copied (useless boilerplate).

Can you accept the patch?

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0281164b-9bf7-485f-83ad-c0301630c91a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BriwVRmoxLBNdrGDzyDmpw8ap6jY5J93ZmV6yco4YoB7R0N4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Allow usage of widgets in generic class-based views?

Alasdair Nicol
This is getting into django-users territory, but I wanted to point out that it's often better to leave out the field instead of using a hidden input.

You can then override the form_valid() method, and set the value before the form is saved.

    class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
model = models.Patient
fields = ['name', 'caregiver_name', 'sex', 'birth_date',
'residence']

        def form_valid(self, form):
            form.instance.country = get_country()  # e.g. get country from self.request.user
            return super().form_valid(form)

Cheers,
Alasdair

On Wednesday, 5 December 2018 16:06:57 UTC, Dan F wrote:
Ah, I see.

It looks like I can use modelform_factory. So:
class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
model = models.Patient
fields = ['name', 'caregiver_name', 'sex', 'birth_date',
'residence', 'country']
becomes
from django.forms.models import modelform_factory

_patient_create_form = modelform_factory(
models.Patient,
fields=['name', 'caregiver_name', 'sex', 'birth_date',
'residence', 'country'])

class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
form_class = _patient_create_form
template_name = 'healthdbapp/patient_form.html'
and then I can add the widgets:

from django.forms import HiddenInput

from django.forms.models import modelform_factory

_patient_create_form = modelform_factory(
models.Patient,
fields=['name', 'caregiver_name', 'sex', 'birth_date',
'residence', 'country'],
widgets={'country': HiddenInput()})

class PatientCreate(LoginRequiredMixin, UserOrgRequiredMixin, CreateView):
form_class = _patient_create_form
template_name = 'healthdbapp/patient_form.html'

Works for me.

On Tue, Dec 4, 2018 at 5:04 PM charettes <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="y261baPzBgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">chare...@...> wrote:
I agree with Tim that this is a slippery slope.

Maybe that adding a ModelFormMixin.get_form_class_options() that returns a
{'fields': self.fields} dict by default and is passed to modelform_factory(**kwargs)
in get_form_class() would be a good compromise?

Best,
Simon

On Tuesday, December 4, 2018 17:28:39 UTC-5, Tim Graham wrote:
What I meant is that modelform_factory() also has these parameters:

localized_fields is a list of names of fields which should be localized.

labels is a dictionary of model field names mapped to a label.

help_texts is a dictionary of model field names mapped to a help text.

error_messages is a dictionary of model field names mapped to a dictionary of error messages.

field_classes is a dictionary of model field names mapped to a form field class.

If we accept the patch for widgets, then are we headed down the road of adding support for the rest of those arguments? Customizing a form directly rather than indirectly via the view seems like better design to me. It doesn't require adding features to ModelFormMixin as they are added to ModelForm.

On Tuesday, December 4, 2018 at 4:57:40 PM UTC-5, Dan F wrote:
<a href="https://code.djangoproject.com/ticket/24589" style="color:rgb(17,85,204)" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F24589\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGduZO3rKB-6F7jwo8_MWU_Z51c-g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F24589\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGduZO3rKB-6F7jwo8_MWU_Z51c-g&#39;;return true;">https://code.djangoproject.com/ticket/24589

This ticket has a patch to pass through the "widgets" argument for generic class-based views.

It was closed with "won't fix" with this comment: "I don't think the possibility of saving a few lines of user code justifies the complexity of reimplementing the parameters to modelform_factory() as CBV parameters and methods."

I don't understand. The patch was quite small (doesn't seem complex), and it could give everyone the ability to overload widgets.

Aside from just saving lines of code, it also would act more as expected. I tried using "widgets" before seeing that it didn't work. Also, it would support not making a new form class where every field just has to be copied (useless boilerplate).

Can you accept the patch?

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="y261baPzBgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="y261baPzBgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-developers@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/0281164b-9bf7-485f-83ad-c0301630c91a%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/0281164b-9bf7-485f-83ad-c0301630c91a%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/0281164b-9bf7-485f-83ad-c0301630c91a%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/0281164b-9bf7-485f-83ad-c0301630c91a%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3d6625e3-51f0-48ff-97f4-332f7e0b6fbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.