From 3a7fc0c7979d53119a7478ef4f614415710b51d7 Mon Sep 17 00:00:00 2001 From: James Bennett Date: Sat, 30 Aug 2008 05:29:19 +0000 Subject: [PATCH] Fixed #8247: Added explanation to admin docs to point out that AdminSite can be subclassed and instantiated like any other Python class git-svn-id: http://code.djangoproject.com/svn/django/trunk@8732 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/ref/contrib/admin.txt | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/docs/ref/contrib/admin.txt b/docs/ref/contrib/admin.txt index 06e45f6bf6..ffde251f88 100644 --- a/docs/ref/contrib/admin.txt +++ b/docs/ref/contrib/admin.txt @@ -226,7 +226,7 @@ You have four possible values that can be used in ``list_display``: list_display = (upper_case_name,) * A string representing an attribute on the ``ModelAdmin``. This behaves - the same as the callable. For example:: + same as the callable. For example:: class PersonAdmin(admin.ModelAdmin): list_display = ('upper_case_name',) @@ -852,6 +852,19 @@ information. ``AdminSite`` objects ===================== +A Django administrative site is represented by an instance of +``django.contrib.admin.sites.AdminSite``; by default, an instance of +this class is created as ``django.contrib.admin.site`` and you can +register your models and ``ModelAdmin`` instances with it. + +If you'd like to set up your own administrative site with custom +behavior, however, you're free to subclass ``AdminSite`` and override +or add anything you like. Then, simply create an instance of your +``AdminSite`` subclass (the same way you'd instantiate any other +Python class), and register your models and ``ModelAdmin`` subclasses +with it instead of using the default. + + Hooking ``AdminSite`` instances into your URLconf -------------------------------------------------