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 <https://code.djangoproject.com/ticket/20000>-- 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! On Tuesday, August 21, 2012 2:55:45 AM UTC-4, Jannis Leidel wrote: > > 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
