Hi Carlton, On Sat, Jan 20, 2018 at 9:13 AM, Carlton Gibson <[email protected]> wrote:
> Hi Raffaele, > > Thanks for both your effort and your patience. > > There are around 60 patches needing review (or just reviewed or being > improved or...) at the moment, so it can take a while to get to. > > I will look at this issue on Monday. > Thanks! > Please don't loose heart. ๐ > Don't worry๐ > Kind Regards, > > Carlton > > > On Friday, 19 January 2018 22:41:22 UTC+1, Raffaele Salmaso wrote: >> >> Hi all, >> as these PR have merge conflicts that need to be resolved, and it takes >> time to keep that ready to merge, I would be glad to know if continue to >> work on them (and how to get them merged) or just drop them and carry on. >> >> Thanks >> >> On Tue, Sep 5, 2017 at 10:57 AM, Raffaele Salmaso <[email protected]> >> wrote: >> >>> 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_con >>> fig('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 >>> >> >> >> >> -- >> | 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/ms > gid/django-developers/9b5418c5-5828-40b0-8f3e-dac9d50fd26c%4 > 0googlegroups.com > <https://groups.google.com/d/msgid/django-developers/9b5418c5-5828-40b0-8f3e-dac9d50fd26c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- | 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/CABgH4Ju9QfHO5k3FQR4nAAE_VU_eb7b1EwSupLA%2BZ9%3DjGakW-Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
