I think the metasystem is one of Django's greatest strengths. Django's admin system has literally cut my development time down by weeks for most projects. The admin system does 90% of what I need, but getting the other few features requires a lot more work than it should. I think this should be relatively simple to fix though. rjwittams did a great job in refactoring the metasystem. I think it can be taken a little further. Here's a list of a few places I think the admin system could be more extensible. I think all of these are reasonable and generic enough to be included in django.contrib.admin, please comment if you think otherwise.
1. Allow overrides of the H1 at the top of the content div. A new template block surrounding the H1 tag would allow for this. I've added a patch in ticket #1090 [1] 2. The admin system already allows you to override admin/change_form, admin/change_list, either for an app, or for a specific model. It should allow overriding of delete_confirmation and object_history in the same fashion. I've added a patch for this in ticket #1089 [2] 3. The RelatedObjectLookup javascript should be applied to OneToOneField. It isn't. I see no reason why it shouldn't be. I've added a solution (just copy a file) in ticket #1100 [3] 4. Application pages in the metasystem. Currently, /admin/myapp/ returns a 404. There should be template (maybe called app_index) that simply displays the models for myapp. The renderer should of course look in admin/myapp/app_index first so users can override the default. I know Jacob mentioned something similar [4] on the dev list. I already have a hack that does this. I still need to take a look at the code in the magic-removal branch to do it right though. 5. Allow overrides of the save-row div in admin/change_form by extending the template. Once again, a template block should allow for this. 6. In addition to 5, The redirect url should be customizable without having to override the default admin urls. There are several possibilities I can think of here. I think the most promising ones won't become apparent until the magic-removal stuff is done. Here are the options I've thought of though. 1. Add a get_add_redirect(request, new_object) to the inner META (or ADMIN class if that ends up happening.) 2. Do something similar to the TEMPLATE_CONTENT_PROCESSORS framework. 3. Events. The first or second option seem the most "djangonic" to me, but that's probably because the event system hasn't landed yet. I don't have strong preferences for any of them yet though. Some of the changes to the way the inner Meta class works in the magic-removal branch may provide some other options here. 7. Allow custom auditing methods ''without'' having to create a custom view. I've seen a lot of people ask for this, and I have yet to see an explanation of how to do it ''without creating a custom view''. I've tried quite a few things, and can't get it to work. People seem to initially want access to the request object in _pre_save(), but of course it doesn't work because the user object isn't available in _pre_save/_post_save. rjwittams has talked about using events in the new magic-removal branch to customize the audit functionality. (I think anyhow, sorry if I'm putting words in your mouth.) This may be the way to go. The crucial thing for auditing is that the request (or at least the user) is accessible in the event object. The request isn't (and IMHO shouldn't be) in current pre-save/post-save signals. Maybe a pre-web-save and post-web-save signal? I know Adrian is concerned about requiring a request object for when you are doing things programmatically and there *is* no request. These could also be added to generic create/add views. Any other places where you think the admin system should allow for customization? Joseph [1] http://code.djangoproject.com/ticket/1090 [2] http://code.djangoproject.com/ticket/1089 [3] http://code.djangoproject.com/ticket/1100 [4] http://groups.google.com/group/django-developers/tree/browse_frm/thread/92729d4f3176b656/3e5aa32ec4d748fc?rnum=1&_done=%2Fgroup%2Fdjango-developers%2Fbrowse_frm%2Fthread%2F92729d4f3176b656%2F3e5aa32ec4d748fc%3Ftvc%3D1%26#doc_cad7102bec5a651f
