python django入门源码

===================== The Django admin site ===================== .. module:: django.contrib.admin :synopsis: Django's admin site. One of the most powerful parts of Django is the automatic admin interface. It reads metadata in your model to provide a powerful and production-ready interface that content producers can immediately use to start adding content to the site. In this document, we discuss how to activate, use and customize Django's admin interface. Overview ======== The admin is enabled in the default project template used by :djadmin:`startproject`. For reference, here are the requirements: 1. Add ``'django.contrib.admin'`` to your :setting:`INSTALLED_APPS` setting. 2. The admin has four dependencies - :mod:`django.contrib.auth`, :mod:`django.contrib.contenttypes`, :mod:`django.contrib.messages` and :mod:`django.contrib.sessions`. If these applications are not in your :setting:`INSTALLED_APPS` list, add them. 3. Add ``django.contrib.messages.context_processors.messages`` to the ``'context_processors'`` option of the ``DjangoTemplates`` backend defined in your :setting:`TEMPLATES` as well as :class:`django.contrib.auth.middleware.AuthenticationMiddleware` and :class:`django.contrib.messages.middleware.MessageMiddleware` to :setting:`MIDDLEWARE_CLASSES`. (These are all active by default, so you only need to do this if you've manually tweaked the settings.) 4. Determine which of your application's models should be editable in the admin interface. 5. For each of those models, optionally create a ``ModelAdmin`` class that encapsulates the customized admin functionality and options for that particular model. 6. Instantiate an ``AdminSite`` and tell it about each of your models and ``ModelAdmin`` classes. 7. Hook the ``AdminSite`` instance into your URLconf. After you've taken these steps, you'll be able to use your Django admin site by visiting the URL you hooked it into (``/admin/``, by default). Other topics ------------ .. toctree:: :maxdepth: 1 actions admindocs .. seealso:: For information about serving the static files (images, JavaScript, and CSS) associated with the admin in production, see :ref:`serving-files`. Having problems? Try :doc:`/faq/admin`. ``ModelAdmin`` objects ====================== .. class:: ModelAdmin The ``ModelAdmin`` class is the representation of a model in the admin interface. Usually, these are stored in a file named ``admin.py`` in your application. Let's take a look at a very simple example of the ``ModelAdmin``:: from django.contrib import admin from myproject.myapp.models import Author class AuthorAdmin(admin.ModelAdmin): pass admin.site.register(Author, AuthorAdmin) .. admonition:: Do you need a ``ModelAdmin`` object at all? In the preceding example, the ``ModelAdmin`` class doesn't define any custom values (yet). As a result, the default admin interface will be provided. If you are happy with the default admin interface, you don't need to define a ``ModelAdmin`` object at all -- you can register the model class without providing a ``ModelAdmin`` description. The preceding example could be simplified to:: from django.contrib import admin from myproject.myapp.models import Author admin.site.register(Author) The register decorator ---------------------- .. function:: register(*models, [site=django.admin.sites.site]) .. versionadded:: 1.7 There is also a decorator for registering your ``ModelAdmin`` classes:: from django.contrib import admin from .models import Author @admin.register(Author) class AuthorAdmin(admin.ModelAdmin): pass It is given one or more model classes to register with the ``ModelAdmin`` and an optional keyword argument ``site`` if you are not using the default ``AdminSite``:: from django.contrib import admin from .models import Author, Reader, Editor from myproject.admin_site import custom_admin_site @admin.register(Author, Reader, Editor, site=custom_admin_site) class PersonAdmin(admin.ModelAdmin): pass Discovery of admin files ------------------------ When you put ``'django.contrib.admin'`` in your :setting:`INSTALLED_APPS` setting, Django automatically looks for an ``admin`` module in each application and imports it. .. class:: apps.AdminConfig .. versionadded:: 1.7 This is the default :class:`~django.apps.AppConfig` class for the admin. It calls :func:`~django.contrib.admin.autodiscover()` when Django starts. .. class:: apps.SimpleAdminConfig .. versionadded:: 1.7 This class works like :class:`~django.contrib.admin.apps.AdminConfig`, except it doesn't call :func:`~django.contrib.admin.autodiscover()`. .. function:: autodiscover This function attempts to import an ``admin`` module in each installed application. Such modules are expected to register models with the admin. .. versionchanged:: 1.7 Previous versions of Django recommended calling this function directly in the URLconf. As of Django 1.7 this isn't needed anymore. :class:`~django.contrib.admin.apps.AdminConfig` takes care of running the auto-discovery automatically. If you are using a custom ``AdminSite``, it is common to import all of the ``ModelAdmin`` subclasses into your code and register them to the custom ``AdminSite``. In that case, in order to disable auto-discovery, you should put ``'django.contrib.admin.apps.SimpleAdminConfig'`` instead of ``'django.contrib.admin'`` in your :setting:`INSTALLED_APPS` setting. .. versionchanged:: 1.7 In previous versions, the admin needed to be instructed to look for ``admin.py`` files with :func:`~django.contrib.admin.autodiscover()`. As of Django 1.7, auto-discovery is enabled by default and must be explicitly disabled when it's undesirable. ``ModelAdmin`` options ---------------------- The ``ModelAdmin`` is very flexible. It has several options for dealing with customizing the interface. All options are defined on the ``ModelAdmin`` subclass:: from django.contrib import admin class AuthorAdmin(admin.ModelAdmin): date_hierarchy = 'pub_date' .. attribute:: ModelAdmin.actions A list of actions to make available on the change list page. See :doc:`/ref/contrib/admin/actions` for details. .. attribute:: ModelAdmin.actions_on_top .. attribute:: ModelAdmin.actions_on_bottom Controls where on the page the actions bar appears. By default, the admin changelist displays actions at the top of the page (``actions_on_top = True; actions_on_bottom = False``). .. attribute:: ModelAdmin.actions_selection_counter Controls whether a selection counter is displayed next to the action dropdown. By default, the admin changelist will display it (``actions_selection_counter = True``). .. attribute:: ModelAdmin.date_hierarchy Set ``date_hierarchy`` to the name of a ``DateField`` or ``DateTimeField`` in your model, and the change list page will include a date-based drilldown navigation by that field. Example:: date_hierarchy = 'pub_date' This will intelligently populate itself based on available data, e.g. if all the dates are in one month, it'll show the day-level drill-down only. .. note:: ``date_hierarchy`` uses :meth:`QuerySet.datetimes() <django.db.models.query.QuerySet.datetimes>` internally. Please refer to its documentation for some caveats when time zone support is enabled (:setting:`USE_TZ = True <USE_TZ>`). .. attribute:: ModelAdmin.exclude This attribute, if given, should be a list of field names to exclude from the form. For example, let's consider the following model:: from django.db i