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

1 files changed, 14 insertions, 1 deletions

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
 -------------------------------------------------