Changes between Initial Version and Version 1 of Ticket #27510


Ignore:
Timestamp:
Nov 21, 2016, 5:13:15 PM (8 years ago)
Author:
Tim Graham
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.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #27510

    • Property Easy pickings unset

  • Ticket #27510 – Description

    initial v1  
    11Hello,
    2 I think that only being able to pass the `fields` keyword argument in `ModelFormMixin.get_form_class` is very limiting.
     2I think that only being able to pass the `fields` keyword argument in `ModelFormMixin.get_form_class()` is very limiting.
    33
    4 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.
     4Being 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.
    55
    6 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.
     6The 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.
    77
    8 What is wrong with simply having a `get_modelform_kwargs` function that by default returns `{"fields": self.fields}`? The implementation would be very short.
     8What is wrong with simply having a `get_modelform_kwargs()` method that by default returns `{"fields": self.fields}`? The implementation would be very short.
    99
    1010I'm willing to work on a patch if others agree this is a good idea.
Back to Top