Changes between Version 3 and Version 4 of DjangoSpecifications/NfAdmin/FlexibleAppHandling


Ignore:
Timestamp:
06/18/2008 11:35:17 AM (7 years ago)
Author:
mrts
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DjangoSpecifications/NfAdmin/FlexibleAppHandling

    v3 v4  
    33= Usability improvements for application handling =
    44
    5 Suppose I have 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.
     5Applications 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
    68
    7 Ticket #3591 proposes an `app` configuration directive, this proposal builds upon that.
     9Ticket #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.
    810
    9 == Proposal ==
     11The 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.
    1012
    11 The following should be possible to achieve with the `app` directive:
    12  * '''verbose application names''': specified and implemented in #3591
    13  * '''ordering''': `app('mypkg.auth', 'myauth', 'My cool auth app', weight=1)`. Heavier items sink to the bottom and lighter ones raise to the top. Default is 0, negative weights can be used for pushing apps above those that don't specify weight.
    14  * '''collapsing''': `app('mypkg.auth', 'myauth', 'My cool auth app', style=('collapse',))`. The style argument has similar behaviour to fieldsets styling in ModelAdmin.
    15  * '''descriptions''': `app('mypkg.auth', 'myauth', 'My cool auth app', description='The cool auth app helps you to foo and bar.',))`. Similar to `help_text` in model fields.
    16   * models could have descriptions as well
     13== Proposal: `AppAdmin` class for customizing app listing in admin index ==
     14
     15In #3591, `AppAdmin` class is proposed as a solution for the second role that would allow customizing the presentation of apps in admin index page.
     16
     17At least the following customizations should be possible:
     18 * '''verbose application names''': possibility to override `app().name`
     19 * '''ordering'''
     20 * '''styling''': especially collapsing. A `style` argument that has similar behaviour to fieldsets styling in `ModelAdmin`.
     21 * '''descriptions''': similar to `help_text` in model fields.
     22
     23Models currently have only verbose names, the same flexibility (ordering and descriptions at least) could be easily extended to them.
     24
     25A syntax example follows.
     26
     27{{{
     28class FooAppAdmin(admin.AppAdmin):
     29    name = "Foo" # overrides app().name
     30    description = "An application that does foo"
     31    style = {'classes' : ('collapse',)}
     32    order = 1
     33    models = ( # model order in this list determines their display order in app block
     34      {'model' : BarModel, 'modeladmin' : BarModelAdmin, 'description' : 'A bar model'},
     35      {'model' : BazModel}, # use default ModelAdmin, don't show description
     36   )
     37
     38admin.site.register(FooAppAdmin) # no need for the tedious for model in [A, B, C, D]: admin.site.register(model)
     39}}}
     40
     41Once 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