(ticket #20000 <https://code.djangoproject.com/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<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.
