On Wed, Feb 10, 2016 at 7:25 AM, Tim Graham <timogra...@gmail.com> wrote:
> The introduction to the admin in the docs [0] reads: > > "One of the most powerful parts of Django is the automatic admin >> interface. It reads metadata in your model to provide a powerful and >> production-ready interface that content producers can immediately use to >> start adding content to the site." >> > > I've proposed [1] changing it to: > > "One of the most powerful parts of Django is the automatic admin >> interface. It reads metadata from your models to provide a quick and >> rudimentary interface where trusted users can manage content on your site. >> >> >> The admin has many hooks for customization but beware of trying to use >> those hooks exclusively. If your needs outgrow what the admin provides, it >> may be simpler to write your own views. The admin’s recommended use is as >> an organization’s internal management tool. It’s not intended for building >> your entire front end around." >> > > However several reviewers have made comments like "I worry that the > description of the Admin sells it short. The Admin is actually brilliant > kit and works as advertised." and "Downgrading Django's admin from > "powerful and production ready" to "quick and dirty [old wording]" is very > harsh... And I fear this will not only lower user's expectations, but also > dev's carefulness!" > > I think part of the reason I raise this is that I'm getting weary of > adding hook after hook for customizing every little thing. I worry we'll > end up with an unmaintainable mess at some point. > “At some point”? Yes… some point long ago :-) > The latest proposal that has me thinking about this adds > ModelAdmin.orderable_by > and ModelAdmin.get_orderable_by() for the use case of disabling sorting > of a column in the change list [2]. This topic also came up in the > discussion of whether or not to add ModelAdmin.exclude and > ModelAdmin.get_exclude() [3] (which hasn't been done yet). There's also > an open question about whether or not to add a view permission [4]. I don't > want to discuss each of these decisions on this thread but rather the > broader question of whether putting a lot of effort in this area is a > direction we should pursue. I know there have been some proposals of > "admin2" but realistically I think the admin has too many customizations > points such that superseding it with something new and innovative won't be > feasible from a backwards compatibility standpoint. > > For me, it depends on how much time and energy you’re spending on these enhancements. I agree that a new admin is needed, and at this point, it’s highly unlikely that it will be backwards compatible. The best we could hope for is a solid migration guide, or maybe some sort of compatibility shim. However, in the meantime, for better or worse, we have an admin, and people are using it. If there’s a feature someone wants to add, and they’re sufficiently motivated to develop a patch, and that patch doesn’t make things *worse* (i.e., it’s a well designed feature that doesn’t cause problems), and the review process isn’t excessively onerous (i.e., you’re not having to spend multiple hours reviewing and re-reviewing a patch to make it trunk ready) then I we should accept the patch. Yours, Russ Magee %-) -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/CAJxq849Qo%3Djp6MdzSr84EBLPWKw7w_Z%3Dv7BCHoNnDR4fQ-i39Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
