| 1 | | ''Part of DjangoSpecifications'' |
| 2 | | |
| 3 | | = Usability improvements for application handling = |
| 4 | | |
| 5 | | Applications serve at least two separate roles in Django: |
| 6 | | * encapsulation of application logic and database models into a single package |
| 7 | | * presentation of contained models in admin index page |
| 8 | | |
| 9 | | 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. |
| 10 | | |
| 11 | | 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. |
| 12 | | |
| 13 | | == Proposal: `AppAdmin` class for customizing app listing in admin index == |
| 14 | | |
| 15 | | See #7497. |
| 16 | | |
| 17 | | 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. |
| 18 | | |
| 19 | | At least the following customizations should be possible: |
| 20 | | * '''verbose application names''': possibility to override `app().name` |
| 21 | | * '''ordering''' |
| 22 | | * '''styling''': especially collapsing. A `style` argument that has similar behaviour to fieldsets styling in `ModelAdmin`. |
| 23 | | * '''descriptions''': similar to `help_text` in model fields. |
| 24 | | |
| 25 | | Models currently have only verbose names, the same flexibility (ordering and descriptions at least) could be easily extended to them. |
| 26 | | |
| 27 | | A syntax example follows. |
| 28 | | |
| 29 | | {{{ |
| 30 | | class BarModelAdmin(admin.ModelAdmin): |
| 31 | | description = 'A bar is a bar is a bar' |
| 32 | | ... |
| 33 | | |
| 34 | | class FooAppAdmin(admin.AppAdmin): |
| 35 | | # app = settings.INSTALLED_APPS[0] -- seems largely unneccessary, admin code has access to the app instance already |
| 36 | | name = "Foo" # overrides self.app.name |
| 37 | | description = 'Foo application does foo' |
| 38 | | style = {'classes' : ('collapse',)} |
| 39 | | order = 1 |
| 40 | | models = ( # model order in this list determines their display order in app block |
| 41 | | (BarModel, BarModelAdmin), |
| 42 | | (BazModel, None), # use default ModelAdmin, don't show description |
| 43 | | ) |
| 44 | | |
| 45 | | admin.site.register(FooAppAdmin) # no need for the tedious for model in [A, B, C, D]: admin.site.register(model) |
| 46 | | }}} |
| 47 | | |
| 48 | | 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. |
| | 1 | This page and several others were created by a wiki user who was not and is not affiliated with the Django project. Previous contents of this and other similar pages are not and should not be confused with [http://docs.djangoproject.com/ Django's own documentation], which remains the sole source of official documentation for the Django project. |