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
-~----------~----~----~----~------~----~------~--~---

Reply via email to