Version 9 (modified by anonymous, 11 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 in ModelAdmin.
  • 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 BarModelAdmin(admin.ModelAdmin):
   description = 'A bar is a bar is a bar'

class FooAppAdmin(admin.AppAdmin):
    app = settings.INSTALLED_APPS[0]
    name = "Foo" # overrides
    description = 'Foo application does foo'
    style = {'classes' : ('collapse',)}
    order = 1
    models = ( # model order in this list determines their display order in app block
      (BarModel, BarModelAdmin),
      (BazModel, None), # use default ModelAdmin, don't show description
   ) # no need for the tedious for model in [A, B, C, D]:

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.

Back to Top