Version 5 (modified by 16 years ago) ( diff ) | ,
---|
Part of DjangoSpecifications
Usability improvements for application handling
Applications serve at least two separate roles in Django:
- encapsulation of application logic and database models into a single package
- presentation of contained models in admin index page
Ticket #3591 proposes an app
configuration directive to address the first role, so that application name, path and database tables can be easily customized. The corresponding specification is given in InstalledAppsRevision. This proposal supplements and builds upon that.
The second role has not been addressed yet. Consider the following use case: a project that contains 10 applications, each containing several models. Some of the apps are of primay importance, some are less important. Currently, there is no way to impose either ordering or hide app contents. This confuses users as it's hard to discern important bits from non-important ones.
Proposal: AppAdmin
class for customizing app listing in admin index
In #3591, AppAdmin
class is proposed as a solution for the second role that would allow customizing the presentation of apps in admin index page.
At least the following customizations should be possible:
- verbose application names: possibility to override
app().name
- ordering
- styling: especially collapsing. A
style
argument that has similar behaviour to fieldsets styling inModelAdmin
. - descriptions: similar to
help_text
in model fields.
Models currently have only verbose names, the same flexibility (ordering and descriptions at least) could be easily extended to them.
A syntax example follows.
class FooAppAdmin(admin.AppAdmin): name = "Foo" # overrides app().name description = "An application that does foo" style = {'classes' : ('collapse',)} order = 1 models = ( # model order in this list determines their display order in app block {'model' : BarModel, 'modeladmin' : BarModelAdmin, 'description' : 'A bar model'}, {'model' : BazModel}, # use default ModelAdmin, don't show description ) admin.site.register(FooAppAdmin) # no need for the tedious for model in [A, B, C, D]: admin.site.register(model)
Once the app presentation has been separated into a customizable class, other ideas for building the admin interface in even more clever and flexible way are free to emerge.