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. On Friday, 3 August 2012 17:04:56 UTC+10, DrMeers wrote: > > 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 > * > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/V-9BdhvaeKwJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
