ModelForm.Meta.overrides

[Simon Meers]

A couple of months ago Jannis closed #/17924 [1] as wontfix, stating "I'm violently -1 on the whole topic "meta programming form fields after they've been instantiated", it's a mess. Yes it would be more DRY, but also much harder to know how the hell the form fields are composed as. Just override the form field, it's not a huge deal code wise and much easier to grok." This has since been contested [2] (though for invalid reasons in my opinion).

I'm not sure that Jannis and I were talking about the same thing; the solution I had in mind did not involve changing form-fields after their instantiation, but rather providing a more elegant and flexible mechanism that works in a similar way to ModelForm.Meta.widgets and formfield_callback.

I've put a draft patch together and attached it to [1] which should give a better indication of the intended approach and its flexibility and benefits. There are still a few details to iron out in evolving the ideal implementation, but this at least demonstrates the gist of it. Does anyone else think this is worth exploring?

Simon

[1] https://code.djangoproject.com/ticket/17924

[2] https://groups.google.com/d/msg/django-developers/x_nJ5epfG18/ZSKcPW0_DvAJ

[Tai Lee]

Overall, I like this patch. I think it's a little unbalanced that we provide `Meta.widgets` but no clearly documented way to override other properties on fields without replacing entire fields.

I think the doc changes are pretty helpful to users who are looking for a way to do this, and it is a good thing to treat all field attributes equally instead of special casing widgets.

I also think a class with overrides defined this way will be easier to read visually and easier to detect and manipulate programmatically than hacking `self.fields` inside `__init__()`, which people do now (myself included).

My only concern is the suggestion to use a callback as the key. I can see that this provides more flexibility for users who want to apply a single set of overrides to multiple fields, but I can see it being misused and abused. If people really need to do that, I think they can just construct their overrides dict programmatically and assign it to `Meta.overrides`.

Cheers.

Tai.

[Jannis Leidel]

Simon,

> A couple of months ago Jannis closed #/17924 [1] as wontfix, stating "I'm violently -1 on the whole topic "meta programming form fields after they've been instantiated", it's a mess. Yes it would be more DRY, but also much harder to know how the hell the form fields are composed as. Just override the form field, it's not a huge deal code wise and much easier to grok." This has since been contested [2] (though for invalid reasons in my opinion).
>
> I'm not sure that Jannis and I were talking about the same thing; the solution I had in mind did not involve changing form-fields after their instantiation, but rather providing a more elegant and flexible mechanism that works in a similar way to ModelForm.Meta.widgets and formfield_callback.

Yup, we're talking about the same thing. No matter how you turn it, whether changing attributes of form fields after they've been instantiated *or* providing an "override" for arguments passed to the __init__ of those forms fields it's still unintuitive and not Pythonic.

We added the widgets option to the model form Meta class to allow overriding the widgets without having to specify the whole field again. It helped us solve a annoying bit of reusability of form fields without increasing the number of places users need to be aware of when they write model forms. That works well with widgets since they are clearly defined pieces of code with just one purpose.

Opening up the Meta class to be a place where you can define the arguments passed to the form fields' __init__ method would be a step in the wrong direction because it increases the number of places users need to look for initial arguments of form fields. It's a bad idea to allow users to shoot themselves in the foot like that. We want to promote standard Python behavior, not add more magic to save a couple lines of code.

Jannis

[Tim Graham]

I'd like to revive the discussion here. I think making simple customizations to the default ModelForm fields is a common need that we should try to find some way to address.

Another shot at this is "#2000 -- Allow overriding `label`, `help_text` and `error_messages` for the default fields in `ModelForm`",
but it's gotten mixed reactions (+1 from Jacob & Carl, -1/reluctant -0 from Jannis).

Feedback is appreciated!

[Tim Graham]

(ticket #20000 that is)

On Friday, June 7, 2013 1:36:30 PM UTC-4, Tim Graham wrote:

I'd like to revive the discussion here. I think making simple customizations to the default ModelForm fields is a common need that we should try to find some way to address.

Another shot at this is "#20000 -- Allow overriding `label`, `help_text` and `error_messages` for the default fields in `ModelForm`",