Commit 3a7fc0c7 authored by James Bennett's avatar James Bennett
Browse files

Fixed #8247: Added explanation to admin docs to point out that AdminSite can...

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
parent c0b53b3d
Loading
Loading
Loading
Loading
+14 −1
Original line number Diff line number Diff line
@@ -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
-------------------------------------------------