#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         |       Keywords:
           Triage Stage:  Unreviewed     |      Has patch:  0
    Needs documentation:  0              |    Needs tests:  0
Patch needs improvement:  0              |  Easy pickings:  1
                  UI/UX:  0              |
-----------------------------------------+------------------------
 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.

--
Ticket URL: <https://code.djangoproject.com/ticket/27510>
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/046.8fa52eb6613fd746bab42d31fc9d0187%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to