For a quick glance, the high-level idea looks okay (subject to a deprecation path, of course), however, in my mind it would be more useful to try to move toward enhancing the forms library itself (if possible) so that less admin-specific code is needed. Have you thought about this at all?
On Saturday, January 23, 2016 at 12:03:41 PM UTC-5, Yoong Kang Lim wrote: > > Currently the BaseModelAdmin class has a method called > formfield_for_dbfield which has a conditional block that in turn calls > different formfield_for_* methods depending on the type of database field > it is handling. In order to do any custom logic to these fields we need to > override these methods and/or pass in some arguments as kwargs to override > attributes of the form field. > > In my opinion, a more natural way is to let different objects handle the > customization, rather than BaseModelAdmin. I'm proposing AdminField classes > with a consistent API that others can subclass from and swap with the > defaults if they desire. > > I've done so preliminary work that you can see in this PR: > > https://github.com/django/django/pull/6026 > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d111dc91-87b5-4876-8bd4-20dca16ad729%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
