Начинаем работу с админ-панелью
На этом занятии мы затронем еще один ключевой момент фреймворка Django – работа со встроенной админ-панелью. Она поставляется сразу «в коробке» и доступна для нашего сайта по адресу:
Причем, по умолчанию, фреймворк использует английский язык. Чтобы переключиться на русскую локализацию, нужно в пакете конфигурации в файле settings.py изменить константу LANGUAGE_CODE, установив ее в значение:
LANGUAGE_CODE = 'ru'
И при обновлении страницы увидим русскоязычный вариант админ-панели.
С помощью встроенной админки можно решать практически все типовые задачи, которые нам могут потребоваться. Это и создание пользователей с разными полномочиями (ролями), отображение всех наших приложений, добавление, удаление и изменение записей и так далее. Она подойдет для большинства сайтов так, что создавать свою админ-панель в Django попросту нет необходимости.
Итак, для входа нам нужно ввести имя пользователя и пароль. Но у нас пока их нет и вообще нет ни одного зарегистрированного пользователя в админ-панели. Поэтому, сначала необходимо создать суперпользователя – администратора сайта. Для этого я перейду в терминал и в новой вкладке консоли выполню команду (из каталога проекта coolsite):
python manage.py createsuperuser
Здесь нам будет предложено указать логин (имя пользователя). В учебных целях я укажу root. Далее, нужно ввести адрес электронной почты, пусть это будет root@coolsite.ru. (Почта может быть не существующей в учебном проекте, а вообще, нужно указывать адрес реальной почты, на которую будут приходить служебные сообщения). И, наконец, вводим пароль (1234) и повторяем его. Конечно, такой простой пароль и имя пользователя я использую сугубо в рамках этих занятий. В реальности старайтесь указывать необычные, уникальные имена и большой, сложный пароль, иначе, получив доступ к админ-панели, злоумышленник легко нарушит работу вашего сайта.
Все, суперпользователь создан и мы теперь можем войти в админку, указав root и пароль 1234. На главной странице мы видим два зарегистрированных приложения: «Группы» и «Пользователи». То есть, мы можем создавать новых пользователей уже непосредственно здесь, а также назначать им определенные группы.
Однако, здесь нет нашего приложения women. Почему? Дело в том, что его нужно зарегистрировать, то есть, указать, что мы хотим его видеть в админ-панели. Для этого откроем файл women/admin.py, который отвечает за взаимосвязь приложения с админкой, где мы будем регистрировать наши модели. Вначале импортируем их:
from .models import *
и зарегистрируем модель Women:
admin.site.register(Women)
Возвращаемся в админку и при обновлении главной страницы видим наше приложение и зарегистрированную модель Women. Если щелкнуть по ней, то видим список наших записей и здесь же можем их редактировать, удалять и добавлять новые. Это очень удобно.
И, смотрите, при выборе определенной записи, мы видим кнопку «Смотреть на сайте». Эта кнопка появляется только тогда, когда в модели определена функция get_absolute_url(). Если мы ее закомментируем и обновим админку, то эта кнопка пропадет. Так, что эта функция достаточно часто используется в различных модулях фреймворка Django.
Давайте немного настроим админ-панель, чтобы она выглядела приятнее и дружелюбнее. Первое, что мы сделаем – это заменим название Women на «Известные женщины». Для этого перейдем в файл с моделями (women/models.py) и в классе Women пропишем специальный вложенный класс Meta, который используется админкой для более тонкой настройки модели:
class Women(models.Model): . class Meta: verbose_name = 'Известные женщины'
Здесь verbose_name – это специальный атрибут, отвечающий за название модели. Однако, мы видим, что админ-панель по прежнему добавляет латинскую s в конец нашего имени, то есть, пытается сделать его множественное число. Чтобы явно указать, как будет звучать название во множественном числе, определим еще один атрибут:
class Meta: verbose_name = 'Известные женщины' verbose_name_plural = 'Известные женщины'
Так стало гораздо лучше. Добавим сортировку записей по дате их создания и по заголовку с помощью еще одного атрибута ordering:
class Meta: verbose_name = 'Известные женщины' verbose_name_plural = 'Известные женщины' ordering = ['time_create', 'title']
Как происходит упорядочение по нескольким полям? Сначала идет сортировка по первому полю (в данном случае дате создания), но если даты оказываются равными, то учитывается следующее поле (заголовок) и так далее. Перейдем в админ-панель и видим, что особо ничего не поменялось, записи и так шали в порядке возрастания времени создания. Изменим сортировку по первому полю на противоположную (ставим знак минус):
ordering = ['-time_create', 'title']
и порядок отображения постов также поменялся. Причем, обратите внимание, указанная сортировка будет также влиять на порядок отображения статей и на сайте. Если перейти на главную страницу, то увидим посты в той же последовательности, что и в админке.
Далее, мы поменяем отображение заголовка women приложения на другой – «Женщины мира». Для этого перейдем в файл women/apps.py и в классе конфигурации приложения пропишем атрибут:
class WomenConfig(AppConfig): name = 'women' verbose_name = 'Женщины мира'
Здесь тоже обратите внимание, что все это работает благодаря подключению приложения в пакете конфигурации (файл settings.py) через этот класс:
INSTALLED_APPS = [ . 'women.apps.WomenConfig', ]
Если бы мы написали просто ‘women’, то заголовок «Женщины мира» в админ-панели не появился бы.
Следующим шагом добавим в списке записей дополнительные поля: id, title, время создания, изображение, флаг публикации. Для этого нужно открыть файл women/admin.py и объявить класс, унаследованный от ModelAdmin:
class WomenAdmin(admin.ModelAdmin): list_display = ('id', 'title', 'time_create', 'photo', 'is_published') list_display_links = ('id', 'title') search_fields = ('title', 'content')
Здесь в атрибуте list_display указываем список отображаемых полей, в атрибуте list_display_links – список полей в виде ссылки для перехода к конкретной записи, а атрибут search_fields определяет поля, по которым можно будет производить поиск записей. (В этом классе есть и другие атрибуты, вы можете изучить их самостоятельно).
Зарегистрируем этот класс в функции register:
admin.site.register(Women, WomenAdmin)
причем, WomenAdmin должен обязательно идти после класса модели Women. Возвращаемся в админку и видим все эти поля. Но они имеют английское написание, а нам бы хотелось иметь русские названия. Поправим. Перейдем в класс определения модели Women (women/models.py) и у каждого поля в конструкторе соответствующих классов добавим именованный параметр verbose_name:
class Women(models.Model): title = models.CharField(max_length=255, verbose_name="Заголовок") content = models.TextField(blank=True, verbose_name="Текст статьи") photo = models.ImageField(upload_to="photos/%Y/%m/%d/", verbose_name="Фото") time_create = models.DateTimeField(auto_now_add=True, verbose_name="Время создания") time_update = models.DateTimeField(auto_now=True, verbose_name="Время изменения") is_published = models.BooleanField(default=True, verbose_name="Публикация") cat = models.ForeignKey('Category', on_delete=models.PROTECT, null=True, verbose_name="Категории") .
Теперь имена полей отображаются с нашими значениями.
По аналогии зарегистрируем вторую модель Category. В файле women/admin.py пропишем:
class CategoryAdmin(admin.ModelAdmin): list_display = ('id', 'name') list_display_links = ('id', 'name') search_fields = ('name',)
И вызовем функцию register:
admin.site.register(Category, CategoryAdmin)
Переходим в админку и видим, что появилось второе приложение с набором указанных полей. Также скорректируем все названия. Перейдем в файл women/views.py и в класс Category добавим вложенный класс Meta:
class Meta: verbose_name = 'Категория' verbose_name_plural = 'Категории' ordering = ['id']
Кроме того, у поля name добавим параметр verbose_name:
name = models.CharField(max_length=100, db_index=True, verbose_name="Категория")
Все, теперь мы можем полноценно работать и с рубриками в нашей админ-панели.
Однако, измененное метаописание полей модели (параметр verbose_name) желательно внести и в таблицы БД. Создадим еще один файл миграции командой:
python manage.py makemigrations
и, затем, применим все миграции:
python manage.py migrate
Все, в целом админка у нас настроена и давайте теперь добавим с ее помощью новую запись. Введем в поле title «Ариана Гранде», заполним другие поля, кроме картинки и нажмем добавить. Админка сообщит об ошибке, т.к. поле photo у нас идет как обязательное. Поэтому выберем картинку и сохраним. Запись была добавлена успешно, в поле photo мы видим путь к изображению, а в проекте появилась папка media с загруженной фотографией.
Видите как это удобно: нам не нужно вручную прописывать механизм загрузки изображений, фреймворк Django все берет на себя и делает это автоматически. Это очень круто! Правда, здесь может возникнуть одна проблема, когда загружаются изображения с одинаковыми именами и помещаются в одну папку. Как это обойти мы позже разберем. А сейчас добавим отображение картинок в списке статей на главной странице. Делается это очень просто, в шаблон index.html добавим строчки:
{% if p.photo %} p>img class="img-article-left thumb" src=">">/p> {% endif %}
Мы здесь вначале проверяем: имеется ли вообще какой-либо путь к изображению (так как не у всех наших записей он присутствует), а затем, используем встроенный атрибут url, который возвращает корректный URL-адрес к текущему изображению. Я загружу все изображения для каждой статьи и получим уже более полноценное отображение постов.
Давайте еще немного улучшим нашу админку и сделаем так, чтобы поле is_published можно было редактировать прямо в списке статей. Выполняется это очень просто. В классе WomenAdmin (файл women/admin.py) добавим еще один атрибут:
class WomenAdmin(admin.ModelAdmin): . list_editable = ('is_published',)
И теперь в списке статей в панели появились чекбоксы, где мы можем убирать или ставить галочки, то есть, поле стало редактируемым.
Далее, добавим поля, по которым сможем фильтровать наш список статей. Опять же в классе WomenAdmin прописываем атрибут:
list_filter = ('is_published', 'time_create')
где указываем список полей для фильтрации. Переходим в админку и видим, что справа появилась панель с возможностью выбирать записи по публикации и времени создания.
Вот так в базовом варианте можно выполнять настройку админ-панели и работать через нее с записями таблиц БД.
Видео по теме
#1. Django — что это такое, порядок установки
#2. Модель MTV. Маршрутизация. Функции представления
#3. Маршрутизация, обработка исключений запросов, перенаправления
#4. Определение моделей. Миграции: создание и выполнение
#5. CRUD — основы ORM по работе с моделями
#6. Шаблоны (templates). Начало
#7. Подключение статических файлов. Фильтры шаблонов
#8. Формирование URL-адресов в шаблонах
#9. Создание связей между моделями через класс ForeignKey
#10. Начинаем работу с админ-панелью
#11. Пользовательские теги шаблонов
#12. Добавляем слаги (slug) к URL-адресам
#13. Использование форм, не связанных с моделями
#14. Формы, связанные с моделями. Пользовательские валидаторы
#15. Классы представлений: ListView, DetailView, CreateView
#16. Основы ORM Django за час
#17. Mixins — убираем дублирование кода
#18. Постраничная навигация (пагинация)
#19. Регистрация пользователей на сайте
#20. Делаем авторизацию пользователей на сайте
#21. Оптимизация сайта с Django Debug Toolbar
#22. Включаем кэширование данных
#23. Использование капчи captcha
#24. Тонкая настройка админ панели
#25. Начинаем развертывание Django-сайта на хостинге
#26. Завершаем развертывание Django-сайта на хостинге
© 2023 Частичное или полное копирование информации с данного сайта для распространения на других ресурсах, в том числе и бумажных, строго запрещено. Все тексты и изображения являются собственностью сайта
Poster POS упрощает ведение ресторанного бизнеса
Одна POS-система решает все вопросы:
онлайн-касса, склад, финансы, аналитика и CRM.
- работает в облаке
- устанавливается за 15 минут
- стоит от $29 в месяц
Подходит для любого формата
Poster адаптируется под потребности вашего бизнеса и одинаково хорош как для небольшой кофеточки, так и для сети заведений.
Dark Kitchen Новый
Франшиза, сеть заведений
Удобное рабочее
место официанта
Запускается на обычных планшетах и ноутбуках, поддерживает все типы заказов — в заведении, навынос и доставку.
- легко разобраться и сразу начать продавать
- будет работать, даже если пропадет интернет
Больше, чем просто учёт
Прогнозируйте нагрузку, оптимизируйте меню и склад, привлекайте новых гостей, контролируйте сотрудников. Весь бэк-офис прямо у вас в браузере.
Аналитика Меню Склад Финансы Маркетинг
Аналитика
Встроенные отчеты помогут ответить на важные вопросы о вашем бизнесе — какие позиции самые прибыльные, у кого из сотрудников выше средний чек, сколько денег в месяц уходит на скидки и многое другое.
Меню
Управляйте меню в удобном интерфейсе, меняйте цены в реальном времени, контролируйте себестоимость. ABC-анализ подскажет, какие блюда пользуются спросом и приносят больше выручки.
Склад
Ведите полный складской учет, следите за остатками в реальном времени, проводите быстрые инвентаризации, контролируйте цены закупки и многое другое.
Финансы
Вы легко найдете любую цифру: чистая прибыль за прошлый квартал, сколько ушло на зарплату в феврале и почему не сходится баланс в кассовой смене.
Маркетинг
Привлекайте гостей, запускайте программу лояльности, настраивайте акции и смотрите полную статистику по гостям.
Управляйте бизнесом из любой точки мира
Контролируйте своё заведение со смартфона с бесплатным мобильным приложением Poster Boss для iOS и Android.
- просматривайте отчеты по продажам
- контролируйте остатки и закупки
- добавляйте расходные транзакции на ходу
АВТОМАТИЗАЦИЯ ДОСТАВКИ ЕДЫ
Запустите свою доставку за 1 день
- сайт для заказов с вашим меню, создается в один клик
- приложение для курьеров на iOS и Android
- аналитика по заказам, курьерам и времени доставки
- интеграция с телефонией и Телеграм-ботами
И еще больше решений для вашего бизнеса
Экран на кухню
Приложение Kitchen Kit, которое полностью заменяет принтеры бегунков на кухню. Заказы с рецептурой и описанием тех. карт мгновенно появляются на планшете или мониторе, и ваши повара сразу начинают готовить.
Сайт с меню
Создайте сайт для доставки или заказов навынос в три клика вместе с Poster Shop. Узнать больше
Управление сетью
Управляйте своей сетью или франшизой в одном бэк-офисе Poster Connect. Узнать больше
Интеграция с 1C
Синхронизируйте меню, данные о продажах и складские поставки между Poster и 1С. Узнать больше
Присоединяйтесь к 50 000 заведений,
которые уже попробовали Poster
Создайте аккаунт прямо сейчас. Первые 15 дней бесплатно.
Максим Яворский, владелец кофейни «Have»
Простая установка.
Превосходная поддержка
Poster работает по модели подписки с простыми тарифами для автоматизации доставки. Стоимость от $29 в мес. без скрытых платежей.
Бесплатная поддержка 24/7
Мы всегда на связи — помогаем и обучаем в любое время и в любой ситуации.
Для работы с Poster подойдет обычный планшет или компьютер. Подключайте принтеры чеков, банковские терминалы и другие устройства. Есть готовые комплекты для быстрого старта.
Как мы писали фронтенд собственной панели управления хостингом: фреймворк и бэкдоры
В прошлой статье мы рассказывали, как пришли к идее написать собственную панель управления хостингом и об общей структуре готовой панели.
Сегодня наш фронтенд разработчик Артыш расскажет, как писал фронтенд этой панели: какой выбрали фреймворк, какой антипаттерн считаем хорошим тоном и как защищаться от бэкдоров, если пользуетесь готовыми библиотеками.
Выбор фреймворка: почему искали новый
Предыдущая панель была реализована на собственном фреймворке, написанном на jQuery. Мы сидели на VMManager, он требовал много доработок: по интерфейсу и функционалу, было тяжело сопровождать такой код. Добавление нового функционала в панель со стороны фронта занимало много времени. Понятно, что при желании и на jQuery можно реализовать хороший фреймворк (я до сих пор люблю jQuery) или даже подобие CMS, но это был не оптимальный вариант: начиная скудной документацией по самописному фреймворку и заканчивая не совсем корректной архитектурой самого приложения.
Старая панель была реализована в виде Single Page Application и на этом его хорошие качества заканчивались. После решения очередной головоломки по добавлению кнопки в список, пришло понимание, что нужна альтернатива. Выбор пал на Vue.
Почему SPA?
Single Page Application — идеальный выбор для панели управления. Панель управления в плане рендеринга довольно простая штука, эту работу можно легко доверить браузеру пользователя. К тому же панели не важна SEO-оптимизация, для этого у нас есть основной сайт. Ну и требуемое время на начальную загрузку всех необходимых скриптов пользователи панели воспринимают спокойно в силу специфики самих этих пользователей. Опять же, бекенд у нас получился классическим RestAPI сервисом — для предоставления в будущем открытого API нашим клиентам.
SPA приложение получилось таким легким, что хорошо работает с браузера телефонов и планшетов — мы просто сделали адаптивную верстку и создавать отдельное приложение не пришлось.
Почему Vue?
3 года назад Vue был относительно молодым фреймворком, но уже тогда о нем много говорили и писали, и когда вышел релиз версии 2.0, мы решили сделать ставку на него — и не прогадали. Сначала планировали просто постепенно заменять какие-то компоненты написанные на jQuery и Vue это позволял делать легко. Но потом, после того, как были переписаны довольно объемные компоненты, все таки решили, что лучше переписать вообще все приложение на Vue.
Это бы рискованный шаг и мы решили его сделать по 4 причинам:
- Vue — простой декларативный фреймворк, его понимают даже верстальщики. Если что, под него легко найти разработчика или просто научить товарища. А значит у нас не будет проблем с поиском нового разработчика и его вхождением в проект, если меня переедет трамвай (хвала богам, в моем городе их нет).
- Vue объективно хорош для написания SPA приложений.
- У меня перед глазами был опыт развития React и я предположил, что популярность Vue будет расти так же. Сейчас фреймворк входит в TOP-3 популярных JS-фреймворков (это легко проверить поисковым запросом), уступая только React и Angular. У него хорошая поддержка, развитая экосистема и большое комьюнити.
- Скорость разработки. Лично я сразу стал воспринимать Vue как этакий конструктор и разработка на нем идет довольно быстро: если мне нужен, например, компонент выбора даты, скорее всего на Vue он уже существует, свободен в использовании и опробован сообществом. Я просто устанавливаю компонент в проект, пишу тег и все работает. По сути, наша панель состоит на 70-80% из готовых библиотек. Я имею в виду именно использование компонента, а не размер кодовой базы, который можно проверить командой типа: npx intrinsic/loc
На Хабре есть замечательная статья о Vue от его создателя, а я расскажу о некоторых особенностях нашего приложения.
Синхронизация Vuex с сервисом RestAPI
Часть данных глобального хранилища Vuex в нашем приложении синхронизируется с RestAPI путем обыкновенных запросов по соответствующим адресам. Зачем мы так сделали? Ну хотя бы для того, чтобы основные настройки пользователя не были привязаны к конкретному браузеру конкретного устройства. Можно зайти в нашу панель с компьютера жены или из игрового клуба и при этом получить в то же знакомое окружение, что и было у вас на своей родной машине.
Кроме того, когда синхронизация была только с localStorage, некоторые браузеры при обновлениях теряли содержимое localStorage — оно полностью удалялось. Да и в последнее время прослеживается какая то тенденция к ужесточению политики хранения данных пользователей в куках, например функция в WebKit Intelligent Tracking Prevention — не ровен час они доберутся и до localStorage.
Шина событий
Да, мы используем глобальную шину событий. Как и в любом другом крупном приложении с множеством компонентов, рано или поздно возникает необходимость наладить взаимодействие между не связанными между собой компонентами. Даже через глобальное хранилище. Понятно, что если есть связь родитель-потомок, их взаимодействие стандартно организуется через свойства props в одну сторону и методом $emit в другую, ну или через хранилище, как и описано в рекомендациях Vue.
Но в документации описана и возможность использования глобальной шины событий. У нас в проекте куча форм с разными наборами полей и в некоторых случаях (их немного, но все из них принципиальные) нужно как-то по особенному реагировать на изменение значения поля. Хранить в глобальном хранилище значения всех полей каждой формы не имеет смысла:
- Во-первых, из-за редкой необходимости
- Во-вторых, все наши формы генерируются динамически и набор полей у любой формы может поменяться кардинально.
Взаимодействие RestAPI с панелью
Для большей отзывчивости интерфейса в старом jQuery-фреймворке обратная связь от RestAPI к клиентскому приложению эмулировалась через хитрую систему таймеров: она производила опросы RestAPI с определенным интервалом и перерисовывала узлы DOM, которые затронули изменения.
Это не было идеальным решением: во всех современных браузерах таймеры практически полностью замирают, когда вкладка становится неактивной и получает низкий приоритет. Как результат запрос к RestAPI сервису может запоздать и получить уже неактуальные данные.
Для решения этой проблемы в новой панели я решил использовать связку из модуля Nchan для веб сервера Nginx и новых возможностей HTML5-интерфейсов — EventSource и WebWorker.
Модуль Nchan поддерживает отправку сообщений через Websocket, EventSource и Long-Polling. Я провел несколько тестов и решил использовать EventSource: сообщения могут быть только текстовыми и поток сообщений осуществляется только в одну сторону (от сервера). Это полностью решало поставленную задачу.
Сейчас работу интерфейса EventSource осуществляет в отдельном фоновом потоке WebWorker, независимо от активности вкладки. В этом же потоке организована примитивная очередь сообщений, чтобы ничего не потерялось. Очередь отправляется в основной поток приложения, который свою очередь производит необходимые перерисовки интерфейса, когда ему удобно и позволяет браузер.
Бэкдоры: как и зачем я проверяю безопасность компонентов
Перед подключением библиотеки ее обязательно проверить на безопасность: был случай, когда компонент специально внедрили бэкдор, который позволял заходить на сайт и скачивать данные.
Но чаще дыры в безопасности появляются скорее по неаккуратности разработчиков. В маркетах приложений есть команда, которая проверяет компоненты на безопасность, но она не слишком зубастая и библиотеки лучше проверять вручную.
Я всегда проверяю пакеты на наличие хуков preinstall, install и postinstall в поле “scripts” файла “package.json”. Кроме того, использую статические анализаторы пакетов, такие как retire, snyk и команду “audit” пакетного менеджера npm.
Предупреждения безопасности бывают разных уровней, чаще всего при проверке попадаются некритичные. Иногда, чтобы пролечить библиотеку достаточно обновиться — разработчики библиотек сами следят за безопасностью.
Если библиотека однажды себя скомпрометировала, лучше ее заменить — это признак неблагонадежности, поэтому при предупреждениях я выбираю искать другую библиотеку.
После того, как пакет прошел анализ, я обязательно фиксирую его версию. Если нужна другая версия — пакет проходит анализ заново. Да, это занимает время, но оно того стоит.
Пока бэкдоры ни разу не попадали к нам на продакшн.
Много-много комментариев
Как я уже говорил, Vue был выбран за простоту и декларативность. В дополнение к этому я пишу много комментариев, практически к каждой строчке: чтобы в случае чего новый разработчик мог легко войти в проект и чтобы я сам легко возвращался к старым кускам кода.
За что я полюбил новый фронтенд и панель в целом
Стало проще поддерживать код
Разработка заняла полгода. Теперь я скорее занимаюсь поддержкой панели, свой код не жмет и не натирает.
Клиенты могут быстро получать то, что запрашивали
Стало быстро и удобно добавлять новые функции, которые появились в бекенде: например, оплату для юридических лиц я добавил за 2 дня, снепшоты — за 1 день.
Я открыт к вопросам
В этой статье я приоткрыл часть секретов, связанных с фронтендом нашей панели. Если у вас возникли вопросы ― добро пожаловать в комментарии, я постараюсь ответить.
И, конечно, приглашаю высказать пожелания по улучшению панели.
- панель управления хостингом
- frontend
- front end
- front-end разработка
- vue
- vue.js
- vuex
- backdoor
- single page application
- Блог компании VDSina.ru
- Хостинг
- Информационная безопасность
- VueJS
Руководство Django часть 4: административная панель Django
Теперь, когда модели для сайта местной библиотеки созданы, добавим некоторые «настоящие» данные о книгах, используя административную панель Django Admin. Для начала мы покажем, как зарегистрировать в ней модели, потом как войти и создать какие-нибудь данные. В конце статьи мы покажем некоторые способы дальнейшего улучшения вида админ-панели.
| Предусловия: | Сначала завершите: Руководство часть 3: использование моделей. |
|---|---|
| Цель: | Уяснить преимущества и ограничения админ-панели Django, научиться использовать её для создания записей для наших моделей. |
Обзор
Приложение Django admin может использовать ваши модели для автоматического создания части сайта, предназначенной для создания, просмотра, обновления и удаления записей. Это может сэкономить вам много времени в процессе разработки, упрощая тестирование ваших моделей на предмет правильности данных. Оно также может быть полезным для управления данными на стадии публикации, в зависимости от типа веб-сайта. Проект Django рекомендует это приложение только для управления внутренними данными (т.е.для использования администраторами, либо людьми внутри вашей организации), так как модельно-ориентированный подход не обязательно является наилучшим интерфейсом для всех пользователей и раскрывает много лишних подробностей о моделях.
Все необходимые настройки, которые необходимо включить в admin приложение вашего веб-сайта, были сделаны автоматически, когда вы создали каркас проекта ( информацию о необходимых актуальных зависимостях смотрите здесь — Django docs) . В результате все, что необходимо сделать для того, чтобы добавить модели в приложение admin, это зарегистрировать их. В конце этой статьи мы представим краткую демонстрацию того, каким образом можно дополнительно настроить админ-панель для лучшего отображения данные наших моделей.
После регистрации моделей мы покажем как создать нового суперпользователя , войти на сайт от его имени и создать книги, авторов, экземпляры книг и жанры. Это будет полезным для тестирования представлений и шаблонов, которые мы начнём создавать в следующей части руководства.
Регистрация моделей
Вначале откройте файл admin.py в папке приложения (/locallibrary/catalog/admin.py). Пока он выглядит так (заметьте, что он уже содержит импорт django.contrib.admin) :
from django.contrib import admin # Register your models here.
Зарегистрируйте модели путём вставки следующего текста в нижнюю часть этого файла. Этот код просто импортирует модели и затем вызывает admin.site.register для регистрации каждой из них.
from .models import Author, Genre, Book, BookInstance admin.site.register(Book) admin.site.register(Author) admin.site.register(Genre) admin.site.register(BookInstance)
Примечание: Если вы приняли участие в создании модели для представления естественного языка книги (см. обучающую статью о моделях), импортируйте и зарегистрируйте её тоже!
Это самый простой способ регистрации модели или моделей. Админ-панель имеет множество настроек. Мы рассмотрим другие способы регистрации ваших моделей ниже.
Создание суперпользователя
Для того, чтобы войти в админ-панель, нам необходимо иметь учётную запись пользователя со статусом Staff (сотрудники). Для просмотра и создания записей, пользователю также понадобится разрешение для управления всеми нашими объектами. Вы можете создать учётную запись «superuser», которая даёт полный доступ к сайту и все необходимые разрешения, используя manage.py.
Для создания суперпользователя вызовите следующую команду из той же папки, где расположен manage.py. Вас попросят ввести имя пользователя, адрес электронной почты и надёжный пароль.
bash
Вход в админ-панель и её использование
Для входа в админ-панель откройте ссылку /admin (например http://127.0.0.1:8000/admin) и введите логин и пароль вашего нового суперпользователя (вас перенаправят на login-страницу и потом обратно на /admin после ввода всех деталей).
В этой части сайта отображаются все наши модели, сгруппированные по установленному приложению. Вы можете кликнуть на названии модели, чтобы получить список всех связанных записей, далее можете кликнуть на этих записях, для их редактирования . Также можно непосредственно кликнуть на ссылку Add, расположенную рядом с каждой моделью, чтобы начать создание записи этого типа.
Кликните на ссылке Add справа от Books, чтобы создать новую книгу (появится диалоговое окно как на картинке внизу). Заметьте, что заголовок каждого поля - это тип используемого виджета, и
help_text(если есть) совпадает со значением, которое вы указали в модели.Введите значение для полей. Вы можете создавать новых авторов или жанры, нажимая на значок "+ ", расположенный рядом с соответствующим полем (или выберите существующее значение из списков, если вы уже создали их). Когда вы закончили, нажмите на SAVE,Save and add another, или Save and continue editing, чтобы сохранить записи.
Примечание: А сейчас, хотелось бы, чтобы вы добавили несколько книг, авторов и жанров (например, Фэнтези) в ваше приложение. Удостоверьтесь, что каждый автор и жанр включает пару различных книг (позже, когда мы реализуем представления "list" и "detail", это сделает их более интересными).
После того, когда книги добавлены, для перехода на главную страницу админ-панели кликните на ссылке Home в верхней части страницы. Потом кликните на ссылке Books для отображения текущего списка книг (или на одной из других ссылок, чтобы увидеть список соответствующей модели). После добавления нескольких книг список может выглядеть наподобие скриншота ниже. Отображается название каждой из книг. Его возвращает метод
__str__()в модели Book, созданной в предыдущей статье.
Для удаления книги из этого списка выберите чекбокс рядом с ней и действие delete. из выпадающего списка Action, а затем нажмите кнопку Go. Также можно добавить новую книгу, нажав на кнопку ADD BOOK.
Вы можете редактировать книгу, кликнув по ссылке с её названием. Страница редактирования книги, приведённая ниже, практически идентична странице добавления новой книги. Основные отличия - это заголовок страницы (Change book) и наличие кнопок Delete, HISTORY и VIEW ON SITE. Последняя присутствует, так как мы определили метод
get_absolute_url()в нашей модели.
Теперь перейдите назад на страницу Home (используя ссылку Home в навигационной цепочке вверху страницы) и просмотрите списки Author и Genre. В них уже должно быть несколько элементов, созданных при добавлении новых книг. Если хотите, добавьте ещё.
Однако у вас не будет ни одного экземпляра книги, потому что они не создаются из модели
Book(хотя можно создать книгу из моделиBookInstance— такова природа поляForeignKey). Для отображения страницы Add book instance (см. рисунок ниже) вернитесь на страницу Home и нажмите кнопку Add. Обратите внимание на длинный уникальный Id для идентификации конкретного экземпляра книги в библиотеке.
Создайте несколько экземпляров для каждой из ваших книг. Установите статус Available (доступен) для некоторых экземпляров и On loan (выдан) для остальных. Если статус экземпляра notAvailable (недоступен), то также установите дату возврата (Due back).
Вот и все! Вы изучили как запустить и использовать админ-панель. Также были созданы записи для
Book,BookInstance,GenreиAuthor, которые можно будет использовать после создания наших собственных представлений и шаблонов."Продвинутая" конфигурация
Django выполняет неплохую работу по созданию базовой админ-панели используя информацию из зарегистрированных моделей:
- каждая модель имеет список записей, каждая из которых идентифицируется строкой, создаваемой методом
__str__()модели, и связана с представлением для её редактирования. По умолчанию, в верхней части этого представления находится меню действий, которое может быть использовано для удаления нескольких записей за раз- Формы для редактирования и добавления записей содержат все поля модели, которые расположены вертикально в порядке их объявления в модели.
Можно настроить интерфейс пользователя для упрощения его использования. Некоторые доступные настройки:
- List views:
- добавление дополнительных отображаемых полей или информации для каждой записи.
- добавление фильтров для отбора записей по разным критериям (например, статус выдачи книги).
- добавление дополнительных вариантов выбора в меню действий и места расположения этого меню на форме.
- Detail views
- выбор отображаемых полей, их порядка, группирования и т.д.
- добавление связанных полей к записи (например, возможности добавления и редактирования записей книг при создании записи автора).
В этом разделе рассмотрим некоторые изменения для совершенствования интерфейса пользователя нашей местной библиотеки, а именно: добавление дополнительной информации в списки моделей
BookиAuthor, а также улучшение расположения элементов соответствующих представлений редактирования. Пользовательский интерфейс моделейLanguageandGenreизменять не будем, так как это не даст заметного улучшения, поскольку он содержит только по одному полю!Полное руководство по всем возможным вариантам настройки админ-панели можно найти в The Django Admin site (документация Django).
Регистрация класса ModelAdmin
Для изменения отображения модели в пользовательском интерфейсе админ-панели, необходимо определить класс ModelAdmin (он описывает расположение элементов интерфейса, где Model - наименование модели) и зарегистрировать его для использования с этой моделью.
Давайте начнём с модели Author. Откройте файл admin.py в каталоге приложения (/locallibrary/catalog/admin.py). Закомментируйте исходную регистрацию (используя префикс #) этой модели:
js
.site.register(Author)Теперь добавьте новый класс AuthorAdmin и зарегистрируйте его как показано ниже:
# Define the admin class class AuthorAdmin(admin.ModelAdmin): pass # Register the admin class with the associated model admin.site.register(Author, AuthorAdmin)Сейчас мы добавим классы ModelAdmin для моделей Book , и BookInstance . Нам снова нужно закомментировать исходную регистрацию:
.site.register(Book) #admin.site.register(BookInstance)
