Opened 8 years ago

Last modified 8 years ago

#27510 new New feature

Allow custom keyword arguments to modelform_factory in ModelFormMixin — at Version 1

Reported by: Tom Forbes Owned by: nobody
Component: Generic views Version: 1.10
Severity: Normal Keywords:
Cc: Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Tim Graham)

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.

Change History (1)

comment:1 by Tim Graham, 8 years ago

Description: modified (diff)
Easy pickings: unset

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.

Note: See TracTickets for help on using tickets.
Back to Top