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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
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.

Reply via email to