#27510: Allow custom keyword arguments to modelform_factory in ModelFormMixin
-------------------------------+--------------------------------------
Reporter: Tom | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.10
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by Tim Graham):
* easy: 1 => 0
Old description:
> Hello,
> I think that only being able to pass the `fields` keyword argument in
> `ModelFormMixin.get_form_class` is very limiting.
>
> Being able to specify the fields greatly reduces boilerplate and is an
> awesome feature, but the moment you want anything more then you have to
> create a ModelForm. Tim Grayham argues in
> [https://code.djangoproject.com/ticket/24589] that "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.", however I don't believe that it adds any significant
> complexity and sorely missing in some circumstances, and it already
> exists for standard forms via the `get_form_kwargs` functionality.
>
> The main use case for this feature would be adding custom widgets to
> modelforms. For example, if you have a view that can return two different
> sets of fields based on the viewing user and you require one of them to
> have a custom widget for this field then you would have to define two
> separate ModelForms, one with each set of fields. If you then want to add
> another set of fields for a user type then you need yet another
> ModelForm. This gets tiring very fast.
>
> What is wrong with simply having a `get_modelform_kwargs` function that
> by default returns `{"fields": self.fields}`? The implementation would be
> very short.
>
> I'm willing to work on a patch if others agree this is a good idea.
New description:
Hello,
I think that only being able to pass the `fields` keyword argument in
`ModelFormMixin.get_form_class()` is very limiting.
Being able to specify the fields greatly reduces boilerplate and is an
awesome feature, but the moment you want anything more then you have to
create a ModelForm. Tim Graham argues in #24589 that "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.", however I don't believe that it adds any significant
complexity and sorely missing in some circumstances, and it already exists
for standard forms via the `get_form_kwargs()` functionality.
The main use case for this feature would be adding custom widgets to model
forms. For example, if you have a view that can return two different sets
of fields based on the viewing user and you require one of them to have a
custom widget for this field then you would have to define two separate
model forms, one with each set of fields. If you then want to add another
set of fields for a user type then you need yet another model form. This
gets tiring very fast.
What is wrong with simply having a `get_modelform_kwargs()` method that by
default returns `{"fields": self.fields}`? The implementation would be
very short.
I'm willing to work on a patch if others agree this is a good idea.
--
Comment:
I'm not sure. One thing that could be confusing is that the method would
be ignored if `View.form_class` is set. Then we have a similar situation
to #21753 where it would be useful to raise an exception if incompatible
view properties/methods are used. Since the similar ticket got wontfixed
without any further discussion, it would be better to raise the issue on
the DevelopersMailingList. That's a better venue for getting feedback than
this ticket tracker.
--
Ticket URL: <https://code.djangoproject.com/ticket/27510#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/061.3ca41ac4b90904716f1a48fb48c7bc91%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
