Создание сайтов на Django, часть 5. Совершенствуем админку.

В прошлой статье мы собирали модель для нашего блога. Теперь нам предстоит сделать хорошую админку для этой модели.

Как уже говорилось ранее, админка по существу является отдельным приложением. Но она стала уже настолько привычной, что выглядит как неотъемлемая часть Django.

Чтобы задействовать админку, мы добавляли её в INSTALLED_APPS, добавляли URL’ы админки в urls.py и регистрировали созданные нами модели в админке в модуле models.py. В urls.py есть вызов одного метода, с которым мы сейчас проведем небольшой эксперемент. Закомментируйте следующую строчку:

сохраните файл, запустите сервер разработки и зайдите в админку. Сколько моделей вы там увидите? Правильно, всего лишь две, которые создали мы. Остальные модели (пользователи, сайты, простые страницы и т.д.) отображаться не будут. Почему так произошло? Метод autodiscover создан для того, чтобы выносить настройку админки в отдельный модуль — admin.py. И во всех остальных приложениях этот модуль существует. Отключив метод, мы отключили исполнение admin.py и все остальные модели не зарегистрировались. А вот созданные нами зарегистрировались, потому что мы их зарегистрировали в модуле models.py, который по умолчанию выполняется при запуске сервера Django. Поэтому они и не пропали.

Однако с точки зрения красоты структуры, следует все-таки вынести настройку админки в отдельный модуль. Не забыв снова подключить autodiscover, создадим внутри каталога blog файл с именем admin.py, и перенесем туда последние три строчки из models.py. Метод register в качестве первого параметра принимает модель, которую необходимо зарегистрировать. Если в models.py эти модели существовали, то в admin.py их необходимо импортировать. Поэтому добавим туда импорт моделей. В итоге содержимое модуля admin.py будет следующим.

Теперь приступим непосредственно к улучшению админки. У метода register есть второй параметр — модель админки, класс, который описывает отображение и поведение модели в панели администратора. Если параметр не указывается, то по умолчанию подставляется класс django.contrib.admin.ModelAdmin. И чтобы получить более продвинутую админку, именно его мы и будем расширять.

ModelAdmin имеет достаточно большое количество настроек, ознакомится с ними можно здесь — https://docs.djangoproject.com/en/1.5/ref/contrib/admin/. Мы по обыкновению возьмем наиболее часто используемые.

Для начала создадим заготовку следующего вида. После импортов создадим два класса, расширяющих ModelAdmin, и укажим их в качестве админок для наших моделей. Должно получиться примерно следующее:

Теперь добавим первое свойство. Оно характерно для любой модели, в которой используется SlugField. Если вы уже успели попробовать, то поле slug автоматически не заполняется, хотя это было бы очень полезным. Для автоматического заполнения полей существует свойство prepopulated_fields.

prepopulated_fields. В качестве входного параметра принимает словарь (dict), в котором в качестве ключей указаны имена заполняемых полей, а в качестве значений кортежи (tuple), в которых перечисляются поля, на основе которых будет происходить заполнение. Заполним это свойство для CategoryAdmin и BlogEntryAdmin:

Далее настроим отображение списка.

list_display. Указывает, какие поля модели будут отображаться в списке. Является кортежем с перечисленными именами полей, при этом важен порядок: в каком порядке перечислим, в таком и будут отображаться. Сейчас по умолчанию отображается представление записи. Сделаем так, чтобы для категории отображалось и имя, и слаг, а для записи сначала выводились даты создания и публикации, потом заголовок, а потом признак того, черновая это статья или нет.

Запустите сервер, зайдите в админку и насладитесь новым внешним видом списков. НО…, есть одно но. Обратите внимание на список записей в блоге. По умолчанию ссылкой, по которой нужно кликнуть, чтобы войти в редактирование, стала дата создания (как первое поле в списке). Но это можно исправить следующим свойством:

list_display_links. Указывает, какие поля из списка будут представлятся в качестве ссылок для входа в редактирование. Так же, как и предыдущее свойство, это является корежем из полей. В нашей ситуации нам достаточно одного поля и достаточно определить это свойство только для одной модели:

Следующие свойства нам пригодятся для того, чтобы было проще искать нужную запись.

list_filter. В нем перечисляются поля, по которым можно будет выполнить отбор записей. Сам отбор будет генерироваться при помощи штатного механизма приложения admin, нам достаточно просто указать поля. Укажем это свойство для BlogEntryAdmin:

Зайдите в админку и обратите внимание на панель фильтров, которая появилась справа.

date_hierarchy. Указывает поле, по которому определяется иерархия по дате. Это ещё один механизм отбора, работает исключительно с датами, причем с только с одной. Соответственно в свойство передается не кортеж, а строка с именем поля. С появлением этого свойства над таблицей со списком статей появится панель для отбора по дате. Это свойство также укажем только для BlogEntryAdmin:

search_fields. В админке есть встроенный механизм поиска. Соответственно в этом свойстве указываются поля, по которым нужно будет искать. Здесь значением является кортеж:

С настройкой списка на этом остановимся. Осталось привести в порядок внешний вид непосредственно самой записи. Для отображения самой модели настроек не так уж и много, но есть две очень хорошие.

fields и exclude. Будьте осторожны с настройкой fields! Когда она появляется, админка перестает выводить все без исключения поля, а выводит только те, которые перечислены в этом свойстве. В качестве альтернативы используется свойство exclude, в нем перечисляются все поля, которые не должны отображаться. В нашей ситуации я предлагаю исключить из отображаемых полей created_at, так как оно является скорее системным, нежели чем пользовательским, и его не стоит позволять редактировать:

Также для управления полями есть ещё одно свойство, которое позволяет сгруппировать поля.

fieldsets. Принимает в качестве значения кортеж из кортежей (извините за тавталогию). В кортеже первым элементом должно идти название группы, а вторым словарь из параметров группы. Одним из параметров является fields, в котором перечисляются выводимые поля. Названием группы может также являться None, тогда группа выводится без названия. Установим такой параметр fieldsets для BlogEntryAdmin:

Следует отметить, что этот параметр следует использовать так же осторожно, как и fields. Если вы определили fieldsets, то вновь созданные поля не будут появляться в админке, пока вы их не пропишите в этом свойстве.

На этом настройка админки закончилась. Ради интереса, чтобы проверить как было и как стало, можете удалить вторые параметры из метода register и вернуться к изначальному виду админки.

В серьезных приложениях может быть много различных ModelAdmin’ов, и для удобства их распихивают по разным модулям. Тогда, чтобы срабатывал autodiscover, все модули помещают в каталог-пакет admin, а в файле __init__.py размещают только admin.site.register c импортами.

В качестве самостоятельной работы протестируйте свойства ordering и list_editable. Они также принимают значение кортежей из имен полей.

Итоговый модуль admin.py:

[…] прошлой статье мы довели до ума админку и на этом закончили […]