fair enough.

I don´t have a problem with just seperating INSTALLED_APPS from
ADMIN_APPS within the settings-file. I just thought another admin-file
is nicer (but that´s not the key argument of my proposal).

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.admin',
    'movies',
    'stars',
    'cinemas',
    'games',
    'promos',
    'polls',
    'festivals',
    'trailer',
    'user',
    'registration',
    'voting',
    'django.contrib.comments',
    'custom_tags',
    'mediadata',
    'stats',
    'newsletter',
)

ADMIN_APPS = (
    (_('User Management'), {
        'apps': ('django.contrib.auth', 'registration', 'user',)
    }),
    (_('Main Content'), {
        'apps': ('movies', 'stars', 'cinemas', 'festivals',
'trailer',)
    }),
    (_('Games'), {
        'apps': ('games', 'promos', 'polls',)
    }),
    (_('Voting/Comments'), {
        'classes': ('collapsed',),
        'apps': ('voting', 'comments',)
    }),
    (_('Extras'), {
        'classes': ('collapsed',),
        'apps': ('mediadata', 'stats', 'newsletter',)
    }),
)

if you need more details, please let me know.

thanks,
patrick


On 4 Sep., 14:23, Russell Keith-Magee <[email protected]> wrote:
> On Fri, Sep 4, 2009 at 7:19 PM, patrickk<[email protected]> wrote:
>
> > thanks for the reply.
>
> > On 4 Sep., 13:02, Luke Plant <[email protected]> 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 [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
-~----------~----~----~----~------~----~------~--~---

Reply via email to