my thoughts:
1. defining groups within admin.py of each app makes reordering groups
complicated.
2. to assign an app to a group, I have to register that app with a
group - if I want (for example) to assign django.contrib.auth to the
group "User Management", I have to change that app (which breaks
future svn-updates). this is true for almost every 3rd-party app (if I
´m using an svn-checkout).
instead of using a bottom-up structure (registering apps with groups),
why not using a top-down structure (defining groups and assigning
apps).
e.g., you could have a file admin.py within your project and this file
could define the groups:
class UserManagement(AdminGroup):
label = "User Management"
...
'apps': ('django.contrib.auth', 'user',)
regards,
patrick
On 5 Sep., 20:22, Russ Ryba <[email protected]> wrote:
> I'm coming late to the coversation but wanted to add by thoughts on
> the admin index issue. I'm at a campground on a cell phone so
> bandwidth and typing is limited.
>
> I'll try to be specific in my comments.
>
> 1. I think that this should be handled by individual app admin.py. I
> like the idea of just modifying one line in installed_apps to turn an
> application on or off.
>
> 2. I think settings.py should only know about applications. You
> should never specify model sorting or model anything in settings.py.
>
> 3. Admin.py per app should specify grouping and sorting per model.
> First by registering a modrladmin group, then later assigning
> modeladmins to that group.
>
> I would extend the previous example as follows.
>
> class UserManagement(AdminGroup):
> label = "User Management"
> sort_order = 100
> merge_with_existing_group = True
>
> class UserAdmin(ModelAdmin):
> Meta:
> sort_order = 50
> class FooAdmin(ModelAdmin):
> Meta:
> sort_order = 60
>
> admin.site.register(User, UserAdmin, group=UserManagement)
> admin.site.register(Foo, FooAdmin, group=UserManagement)
>
> Then in the index template app groups would be sorted by sort order
> values, then alphanumeric.
>
> - This would keep grouping defined in each app admin class.
> - This would let you sort apps/groups by numerical values.
> - mergewexisting would let apps join together or not, being false by
> default so you could see when name collisions occur with app or group
> names. It could also let complimentary apps extend each other by
> adding new models.
>
> Further thoughts.
>
> - SQL tables are currents based on appname_model, as are the URL
> mappings. Changing the index grouping is essentially the same as
> merging applications.
>
> I love the sound of it if we focus on the index. However I foresee
> the next logical request would be to "fix" the SQL and URL mappings to
> match the index display. That would be practically impossible or very
> ugly.
>
> Name collisions suddenly have to be accounted for, SQL migrations to
> rename tables, as well as permission names.
>
> 4. Thinking about how to implement the URL and SQL mappings leads me
> to suggest a new file App/meta.py. This would contain application
> name override, Application sort order and model grouping would be
> defined here.
>
> The meta class would know about the applications models, and admin
> interfaces and define how to group then all together.
>
> Accessible via something like
>
> Appname.meta.property = value
>
> Since it's define at the app level the SQL and URL processors should
> have access to it.
>
> This could also be a good place to define things I use a lot like
> custom permissions specific to the application per app or per app model.
>
> Maybe I'm getting ahead of myself with URL and SQL stuff?
>
> Comments?
>
> Russ Ryba
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
