Любой, кто ищет способ добавить своё поведение в интерфейс администратора Django, вероятно немного расстраивается. «Всё, что вы рассказали, относится к визуальному преображению интерфейса» — слышится их плач. «Как же мне изменить функционирование интерфейса?»
Первое, что необходимо понять, — в этом нет магии. Следовательно интерфейс администратора не делает ничего особенного — это просто набор представлений,
которые находятся в
django.contrib.admin.views
, для
манипулирования данными.
Естественно, представления содержат немало кода в себе, который работает со всеми этими опциями, типами полей и настройками, которые влияют на поведение модели. Однако, как только вы осознаете, что интерфейс администратора является простым набором представлений, вам будет проще понять процесс добавления своего представления.
Следуя традиции, давайте добавим представление «отчет издателя» к нашему книжному приложению из главы «Интерфейс администратора Django». Мы реализуем представление, которое будет отображать список книг, разбитых по издателям — очень типичный пример своего представления.
Сначала, определим наше представление в схеме URL. Следует вставить эту строку:
(r'^admin/books/report/$', 'mysite.books.admin_views.report'),
перед строкой, которая подключает представления интерфейса администратора. Весь файл со схемой URL может выглядеть так:
from django.conf.urls.defaults import *
urlpatterns = patterns('',
(r'^admin/bookstore/report/$', 'bookstore.admin_views.report'),
(r'^admin/', include('django.contrib.admin.urls')),
)
По какой причине надо определять в схеме URL своё представление
до подключения представлений
административного интерфейса? Следует вспомнить, что Django
обрабатывает шаблоны URL по порядку. Шаблоны административного
интерфейса совпадают почти со всем, что доходит до них. Таким
образом, если мы изменим порядок этих двух строк, Django найдёт
для URL соответствующее совпадение с представлением
административного интерфейса, которое не будет работать так как
надо. В этом конкретном случае, представление попытается
подгрузить список изменений для модели
Report
приложения books,
которого не существует.
Пришло время написать код нашего представления. Для простоты мы
будем загружать информацию обо всех книгах в контекст и позволим
шаблону управлять группировкой с помощью тега {% regroup %}. Создайте файл
books/admin_views.py
с таким кодом:
from mysite.books.models import Book
from django.template import RequestContext
from django.shortcuts import render_to_response
from django.contrib.admin.views.decorators import staff_member_required
def report(request):
return render_to_response(
"admin/books/report.html",
{'book_list' : Book.objects.all()},
RequestContext(request, {}),
)
report = staff_member_required(report)
Раз мы передали ответственность за группировку на шаблон, представление будет очень простым. Тем не менее, существует несколько тонких моментов, которые следует разъяснить:
Мы используем декоратор staff_member_required из django.contrib.admin.views.decorators. Он аналогичен декоратору login_required, который был рассмотрен в главе «Сессии, пользователи и регистрация», но этот декоратор также проверяет вхождение пользователя в группу «staff» и, следовательно, разрешает доступ к интерфейсу администратора.
Этот декоратор защищает все встроенные представления административного интерфейса и организует логику аутентификации вашего представления аналогично логике остального интерфейса.
Мы используем шаблон из каталога
admin/
. Пока явно не сказано обратное, хорошим тоном является хранение всех административных шаблонов в каталогеadmin/
. Мы также разместили наш шаблон в подкаталогеbooks
— это тоже является хорошим тоном.Мы используем
RequestContext
в качестве третьего параметра (context_instance) дляrender_to_response()
. Это делает информацию о текущем пользователе доступной в шаблоне.Для получения подробностей о
RequestContext
обратитесь к главе «Расширения для шаблонной системы».
И в конце следует сделать шаблон для этого представления. Мы будем расширять встроенные шаблоны административного интерфейса так, чтобы визуально наше представление не отличалось от встроенных:
{% extends "admin/base_site.html" %}
{% block title %}List of books by publisher{% endblock %}
{% block content %}
<div id="content-main">
<h1>List of books by publisher:</h1>
{% regroup book_list|dictsort:"publisher.name" by publisher as books_by_publisher %}
{% for publisher in books_by_publisher %}
<h3>{{ publisher.grouper }}</h3>
<ul>
{% for book in publisher.list|dictsort:"title" %}
<li>{{ book }}</li>
{% endfor %}
</ul>
{% endfor %}
</div>
{% endblock %}
Путём расширения admin/base_site.html
мы
сделаем наше представление подобным стандартным, результат
показан на рисунке «Наше представление»:
Вы можете использовать данную методику для реализации в административном интерфейсе всего, о чём вы только могли мечтать. Просто не забывайте, что эти так называемые свои представления являются простыми представлениями Django. Вы можете использовать все методики, которые описаны в данной книге, для создания настолько сложных представлений для административного интерфейса, насколько это необходимо.
Мы завершим эту главу несколькими идеями по настройке административных представлений.
Пред. | Уровень выше | След. |
Настройка шаблонов интерфейса | Начало | Переопределение встроенных представлений |
0 comments | Make a comment