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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
