On Sat, Sep 5, 2009 at 3:32 AM, James Bennett<[email protected]> wrote: > > On Fri, Sep 4, 2009 at 2:21 PM, andybak<[email protected]> wrote: >> 1. I think worrying about projects vs. apps is a red-herring. We are >> talking about a way to configure an admin app. There might be several >> of these on a 'site/project/whatever' > > Since this all seems to be specific to particular instances of > AdminSite, AdminSite would be the logical place to do it if it's going > to get code-level support. However... > >> 2. Some ability to regroup and choose better names is a biggie. It >> pains me when I try and explain to my admins what 'auth' means... > > Practically everything being requested here is purely presentational. > And Django has a component for doing presentational logic: the > template system. The admin templates are deliberately easy to override > with custom versions, and it feels like all of this is really just > asking for things that are more cleanly done in templates.
This isn't completely true - at least, not if you want to affect the URL structure as well. If you're just looking be able to use: /admin/<app>/<model> and replace that with: /admin/<app group>/<model> then you need some form of representation at the code level. This can't be done purely with templates. This distinction is really only important if you want the URL structure to reflect of logical structure, rather than code structure (which, broadly speaking, is a good thing to be doing from the "URL as interface" argument). However, this use case could be handled at present with a custom site that overrides get_urls to provide the 'group' landing page, etc. I can see that providing a DSL-style way to set up these groups could be handy for a small group of users, but I can't say it's a particularly compelling use case for me personally. I strongly suspect that this could (and therefore, should) be handled as an external project in the initial phases - i.e., a "django-extended-admin' project that provides the AdminSite and ModelAdmin extensions that would make a DSL-for-groups approach possible. Patrick, Joshua - if you're enthused about this idea, I suggest you combine your efforts and try to make this external project a reality. If this external project gains traction, then we can look at merging it back to trunk. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
