Opened 8 years ago
Last modified 8 years ago
#27510 new New feature
Allow custom keyword arguments to modelform_factory in ModelFormMixin — at Initial Version
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 |
Pull Requests: | How to create a pull request | ||
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.
According to the ticket's flags, the next step(s) to move this issue forward are:
Unknown. The Someday/Maybe triage stage is used to keep track of high-level ideas or long term feature requests.
It could be an issue that's blocked until a future version of Django (if so, Keywords will contain that version number). It could also be an enhancement request that we might consider adding someday to the framework if an excellent patch is submitted.
If you're interested in contributing to the issue, raising your ideas on the Django Forum would be a great place to start.