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
This commit is contained in:
James Bennett 2008-08-30 05:29:19 +00:00
parent c0b53b3dcc
commit 3a7fc0c797
1 changed files with 14 additions and 1 deletions

View File

@ -226,7 +226,7 @@ You have four possible values that can be used in ``list_display``:
list_display = (upper_case_name,) list_display = (upper_case_name,)
* A string representing an attribute on the ``ModelAdmin``. This behaves * 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): class PersonAdmin(admin.ModelAdmin):
list_display = ('upper_case_name',) list_display = ('upper_case_name',)
@ -852,6 +852,19 @@ information.
``AdminSite`` objects ``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 Hooking ``AdminSite`` instances into your URLconf
------------------------------------------------- -------------------------------------------------