tickets: 7497
This data as json
| id | created | changetime | last_pulled_from_trac | stage | status | component | type | severity | version | resolution | summary | description | owner | reporter | keywords | easy | has_patch | needs_better_patch | needs_tests | needs_docs | ui_ux |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 7497 | 2008-06-18 18:03:33 | 2022-03-05 16:12:31 | 2022-03-06 03:39:47.605078 | Accepted | new | contrib.admin | New feature | Normal | dev | AppAdmin class for customizing app listing in admin index | See http://code.djangoproject.com/wiki/DjangoSpecifications/NfAdmin/FlexibleAppHandling for details. This '''supplements''' the `app` directive. As discussed with `brosner` and `jkocherhans` in #django-dev: {{{ <brosner> it looks reasonable, but haven't spent much time thinking about it <jkocherhans> mrts: I think this is clearly backwards incompatible with the current nfa api and has to go in pre 1.0 if it goes in at all <jkocherhans> I'm a big -1 on the order attribute and -0 on models (maybe just a different syntax), but the other stuff seems reasonable <mrts> jkocherhans: what's wrong with ordering? <jkocherhans> it just feels like the wrong place to specify it <jkocherhans> it's a global issue, and an issue any particular app should handle <mrts> my use case: I have a lot of functionality exposed to somewhat dumb users <mrts> and they have trouble finding the right bits in the admin interface ordering is only used in context of admin index I would like to put the important apps to top and collapse the rest <jkocherhans> exactly. what should 3rd party apps put there? therein lies my objection. <mrts> well, I'd say decouple admin from models (as nfa already does) and don't specify any admin options at all -- users are free to customize things with AppAdmin <jkocherhans> I guess not if using a AppAdmin class is optional. I was originally thinking it would replace model registration with an admin site. <mrts> jkocherhans: yeah, that's what I kinda meant... it looks more coherent this way jkocherhans: and it may solve some of the issues register() currently has <jkocherhans> mrts: I'm gonna have to let it sit for awhile. I'm trying to think of what else an AdminApp class would do besides being a coathanger for a few attributes, nothing is coming to mind. <mrts> jkocherhans: but jezdez has a point -- it would also provide easy bridging for app instances }}} Example syntax 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 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 (BarModel, BarModelAdmin), (BazModel, None), # 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) }}} | nobody | mrts | 0 | 0 | 0 | 0 | 0 | 0 |