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