Hi all, I'm working to ticket #8500 and #27728 to improve a bit the admin, and being asked to ask to django-developers about some decision.
In ticket #8500 I've used a LazyObject to defer the the real django.contrib.admin.sites.site instantiation, so admin.site is always the custom one. The first approach was simpler, with a setting. But as Tim pointed out it doesn't need to be a setting, so I rewrote to be a custom field for (Simple)AdminConfig (and django itself doesn't need to know it existence) Currently I'm monkey patching in my custom admin setup ( https://bitbucket.org/rsalmaso/django-fluo is my own utility library) > class FluoAdminConfig(AdminConfig): > default_site = "fluo.admin.sites.AdminSite" > > def ready(self): > self.override_admin_site() > super().ready() > > def override_admin_site(self): > from django.contrib import admin as django_admin > from django.contrib.admin import sites as django_sites > from fluo import admin as fluo_admin > from fluo.admin.sites import DefaultAdminSite > > site = DefaultAdminSite() where the DefaultAdminSite is the same as in PR > class DefaultAdminSite(LazyObject): > def _setup(self): > AdminSiteClass = import_string(apps.get_app_config('admin').default_site) > self._wrapped = AdminSiteClass() I think it is a better approach than the Jannis' one ( https://code.djangoproject.com/attachment/ticket/8500/8500.1.diff), as Adam claims it is simpler, because - it doesn't require to rewrite your admin.py to add an helper function in admin.py > def register(site): > site.register(...) - it works with all current third party modules (so don't have to add a custom adapter in my own project) - can use the @admin.register() decorator as is Currently all my projects use this approach, and I'm really happy because I find no problem with 3rd apps, they always use my custom instance, and don't have two different site. In ticket #27728 I've rewrite all include template tags (submit_row, pagination, admin_actions, search_form, date_hierarchy, result_list, prepopulated_fields_js, object_tools) to be overridable by the "standard" admin pattern (["admin/app_label/app_model/template_name", "admin/app_label/template_name", "admin/template_name"]). This patch solves even the tickets #11974, #12566, #18957, #19235, #26763. Choose to patch all include tags because: - I have a project where I override all of them (!) - they are all the same implementation, so easy to replicate The approach is to create a custom InclusionAdminNode, which handle all common task to split the include parameters, select the correct template and wrapping the original tag function (which are never changed). Hope this clears all intentions and have them in django 2.0 :) -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- 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/CABgH4JsR_T_72omhqy7xeOvyV0MYAKFZ2eE1Fb18ESVy%2BzC%2BPw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
