On Fri, Sep 4, 2009 at 7:19 PM, patrickk<patr...@vonautomatisch.at> wrote: > > thanks for the reply. > > On 4 Sep., 13:02, Luke Plant <l.plant...@cantab.net> wrote: >> On Friday 04 September 2009 10:00:37 patrickk wrote: >> >> > e.g, when I´m using djangos auth-app and I´m extending the user-model >> > with a user-profile, I´m having "auth" (with users and groups) and >> > "user" (with user profile) on my admin index page. orderd by names, >> > auth is very much on the top of my page while user is at the bottom. >> > for an editor, this is probably hard to understand (because the editor >> > doesn´t know anything about apps). for an editor, it´d more >> > comfortable having a headline "user management" with the apps "users", >> > "groups" and "user profiles". this re-arrangement could be defined in >> > admin.py. >> >> You can also define the arrangement by overriding the admin template for the >> index and hard coding in your own order. It's not ideal, but it's perhaps >> preferable to adding another place for configuring the admin. If you want >> this kind of flexibility for the index page, you might also want to add extra >> notes etc onto the page, which makes customising the template a reasonably >> good way to do it. > > yep. I know that that´s possible, but it leads to another problem: the > app-index is missing. because (referring to my initial example) "user > management" is not an app and therefore it´s not clickable. of course > I could make "user management" a link and define custom templates for > every section of my index-page. > with my proposal, "user management" would be a section containing > different apps. and either "user management" as well as every app > within this section should be clickable. > > moreover, hardcoding the index-template doesn´t seem very clean from > my point of view. > >> Having an admin.py for every project is a bit vague, because 'projects' don't >> really exist as far as Django is concerned, only 'apps'. > > I´m not exactly sure, but I don´t think that´s a huge problem, right? > maybe I used the wrong terms, but it can´t make a big difference > whether the settings-file is used for the admin or another file is > used. however, I could be mistaken.
It depends :-) It is a slight problem in that we currently require no project-level code. Everything besides settings and the top-level URLconf is stored in an application. The admin app is "just another app" - there's nothing specifically "project level" about it. All the current admin registrations, for instance, occur with app-level admin.py files, and you can get very creative about those files. If you can come up with a compelling reason why a top-level admin.py file is required, we're happy to listen to it. > a bit of background information: while using djangos admin-interface > for about 3 years now, customers always complain about not finding > stuff on the admin index page. for a bigger website with about 50 apps > you get a really long list. and I just thought it would be easier if > apps are combined within sections (again, don´t nail me down on the > terms ...). On the face of it, having more ability to customize is always going to be good. The problem is, we need specificity here. So far, all we know about your proposal is that it involves a project-level admin.py. What will be in that file? How will it integrate with the AdminSite? With ModelAdmins? A project-level admin.py file isn't inherently wrong (although I must say I do share Luke's aversion to such a suggestion). However, it really depends on what you intend to put into that file. If you give some concrete suggestions, we can give some concrete feedback. Making suggestions with an eye to potential implementation difficulties (i.e., can we actually push admin to do this?) will gain bonus points. 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 django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
