Django Admin что это такое и зачем


Содержание

Как и почему мы используем Django

Первоначально howchoo был напсиан на PHP и Codeigniter, затем, в феврале 2015 года, мы полностью переключились на Django. Недавно на Reddit я отвечал на вопрос как раз об этой конкретной ситуации: «Мое приложение построено на PHP/Codeigniter, что будет если я перепишу его на Python/Django ?». Я дал краткий ответ, но решил немного подробнее объяснить, почему howchoo использует Django. Или, точнее, за что особенно мы любим Джанго.

Ответ «как» мы используем Django тесно связан с ответом «почему» мы используем Django. Проще говоря, мы используем Django из-за того, что он нам хорошо знаком и имеет массу функций, которые нам могут пригодиться. Конечно, я скоро подробнее расскажу об этих функциях.

При выборе веб-фреймворка и языка можно обращать внимания на несколько вещей — производительность, масштабируемость, устойчивость, сообщество, но я бы сказал, что знакомство с технологией имеет первостепенное значение. Вы, конечно, сблизитесь с любой структурой, которую выберете, но важно начать строить проект с того, с чем вы уже знакомы. Особенно если вы начинаете свой проект с парой парней, которые делают слишком много вещей. Как правило, за использование совершенно новой среды и языка приходиться платить. С учетом сказанного, иногда фреймворк настолько хорош, что стоит идти и на дополнительные расходы. В нашем случае мы были знакомы с Джанго и также считаем, что Джанго наиболее подходит для нашей задачи.

Чтобы обеспечить контекст для следующих тем, вы должны понимать, что важно для Howchoo. Если вы создаете приложение с совершенно другими приоритетами, это руководство может оказаться не таким полезным.

Быстрая загрузка страниц

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

Масштабируемость

Будучи издательской платформой, мы надеемся, что однажды достигнем 100 миллионов пользователей в месяц. Это много. И это также означает большое количество просмотров страниц. И поскольку мы начинали в команде всего из трех инженеров, мы не должны испытывать проблем при увелечении нагрузки. Мы не можем собрать 100 миллионов пользователей, или мы никогда не достигнем 100 тысяч.

Чистый Код как благочестие

Возможно это перебор, но мы все еще считаем полезным писать чистый и организованный код. Это также связано с масштабируемостью, так как нам будет легче масштабировать нашу команду разработчиков, если новые инженеры смогут быстро понять кодовую базу. Документы веб-фреймворка должны быть достаточной документацией для большинства наших приложений.

Ох, а теперь о мясе.

За что мы любим Джанго:

Модели и базы данных

Для начала Django использует модели даннных для создания вашей базы данных. Мне это нравится. Вы можете посмотреть на свою модель Django, чтобы увидеть, какие поля находятся в вашей таблице, и вам никогда не придется напрямую взаимодействовать с базой данных. А в более поздней версии Django (мы сейчас используем 1.7), чтобы обновить схему, вы просто модифицируете свою модель, производите миграции и запускаете миграции.

[add fields to model] ./manage.py makemigrations ./manage.py migrate

И если вы беспокоитесь о том, что придется на самом деле самому это делать, вы можете запустить это после makemigrations, чтобы просто распечатать SQL, который будет запущен (не запускать его).

Кроме того, Django делает запрос к базе данных очень простым.

И обновление это проходит довольно весело.

user.first_name = «Tyler» user.save()

Конечно, большинство веб-фреймворков имеют как минимум функциональный уровень абстракции базы данных (я повторяю больше всего). А Django предоставляет средства для выполнения довольно сложных запросов — более сложных, чем обычно необходимо.

В целом, работа с базами данных не должна быть большой проблемой при создании веб-приложения. Последние версии Django делают управление вашей базой данных безболезненным.

Шаблонирование

Честно говоря, мне не всегда нравилось, как Django обрабатывает шаблоны. Подход заключается в том, что допустимо иметь некоторую логику в шаблонах (или много логики в шаблонах). Сначала меня это немного растроило. Это то, чтопридется использовать даже если и не очень то нужно. Впрочем, я использовал логику в шаблонах, и теперь начинаю думать, что все в порядке. И со временем я обнаружил, что система шаблонов Django более чем достаточна для нужд howchoo.

Маршрутизация

URL-маршрутизация в Django — отличное сочетание мощного и простого функционала. Самое главное, мне нравится, как в Джанго строятся urlpatterns. Файлы urls легко читаются и быстро реагируют на различные действия. Это огромное преимущество для такой неотъемлемой части приложения. Я видел некоторые фреймворки, где маршруты скрыты и немного загадочны. Это не хорошо.

Кэширование

Как говорилось ранее: howchoo изначально был встроен в PHP/Codeigniter. И да, Codeigniter обеспечивает встроенное кэширование страниц, но в конечном итоге это было причиной, по которой я начал пересаживаться на Django. Я знал, что кэширование страниц будет ОГРОМНОЙ частью нашей стратегии по сокращению времени загрузки страницы, и я хотел что-то мощное. С Django вы можете кэшировать части шаблона или всего представления с очень небольшими настройками. Это прекрасно.

Формы и ModelForm

Классы Django Form и ModelForm не красивые, но они достаточно просто и понятно работают. В самом простом случае, если вы используете ModelForm, вы получите работающую форму всего за несколько (менее 10) строк кода. Это включает в себя создание формы HTML, проверку и сохранение. Конечно, большинство форм не являются базовыми, но классы форм очень настраиваемы. Наши guide tool максимально расширяют классы форм, и мы прекрасно с ними работаем.

Пользовательская модель User

Каждый новый проект Django должен использовать пользовательскую модель User. Официальная документация Django гласит, что это «настоятельно рекомендуется», но я сделаю еще один шаг и без колебаний скажу: вы просто с ума сошли, если не использовали пользовательскую модель раньше.

Зачем? Потому что вам придется внести изменения в пользователя в какой-то момент в жизни вашего проекта — добавить поле даты рождения, возраст, что угодно — и если вы не начали с пользовательской модели User до самой первой выполненной вами команды переноса, тогда вы попадете в мир боли.

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

Можно ли переключиться на пользовательскую модель в середине проекта? Да. Хочешь ли ты это сделать? Лучше не делать.

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

Шаг 1. Создание нового проекта

В командной строке перейдите в новый каталог для своих проектов, используйте Pipenv для установки Django, активируйте виртуальную среду и создайте новый проект с именем new_project . Давайте предположим, что мы хотим использовать папку code в Desktop , так пример на Mac.

Теперь нам нужно создать приложение пользователя, а затем обновить 4 файла. Готовы?

Шаг 2. Создание приложения пользователя

Теперь давайте расскажем Django о новом приложении и обновим AUTH_USER_MODEL , чтобы Django знал, что нужно использовать нашу новую модель CustomUser вместо модели User по умолчанию.

Откройте new_project/settings.py в текстовом редакторе и внесите следующие два изменения:

Шаг 3. Модель CustomUser

Мы хотим расширить (или скопировать) существующую модель User и назвать ее как-то иначе, в нашем случае CustomUser . Это все, что нам нужно сделать. Просто сделайте копию, и тогда мы сможем настроить ее так, как нам нравится, но при этом использовать все преимущества встроенного User .

Нам даже не нужно добавлять поле на этом этапе!

Шаг 4: Обновление форм

Django использует модель User — теперь нашу модель CustomUser , поскольку мы указали ее в AUTH_USER_MODEL повсюду. Два основных места — это когда создается новый пользователь и когда мы что-то меняем у пользователя. Поэтому мы должны снова расширить встроенные формы для этого и указать их для нашей новой модели CustomUser .

Создайте новый файл users/forms.py и заполните его следующим текстом:

Шаг 5: Обновление admin.py

Модель Django User тесно связана с превосходным встроенным приложением администратора admin , поэтому мы должны указать Django использовать вместо этого CustomUser . Вот как:

И это все. Создайте файл миграции для наших изменений, а затем впервые запустите миграцию, чтобы инициализировать нашу базу данных с помощью CustomUser вместо User .

Поздравляем! Ваш проект Django рассчитан на будущее и вы можете продолжить работу без проблем.

Кастомизация админки Django

Что такое админка в django и зачем ее кастомизировать, я думаю, вы уже знакомы. Для кастомизации админики есть множество инструментов, наподобие django-admin-tools и django-admin2. Но мы не будем рассматривать их в этой статье, а кастомизируем ее с помощью самой джанго. И увидим, что это не так трудно, как кажется:Итак, начнем с того, что админка django — это отдельное приложение, которое находится в django\contrib\admin. Исходники в сети можно увидеть на официальном сайте django.

С чего начнем? Как правило, чтобы кастомизировать админку django, надо унаследоваться от ModelAdmin.

Создадим admin.py в корне папки нашего приложения и напишем в нем следующие строки:

И мы можем добавить нашу модель для отображения вот так:

Первый шаг положен. И первое, что, как правило, необходимо в админке — это изменение ее внешнего вида, например, названия сайта в заголовке.

Итак, идем в Lib\site-packages\django\contrib\admin\templates\admin нашего виртуального окружения либо папки с Python. В моем случае — D:\django\hello\Lib\site-packages\django\contrib\admin\templates\admin. Ищем там base_site.html и копируем его в папку с шаблонами своего проекта в подпапку admin: templates\admin . Открываем его и видим следующую картину:

Все, готово . Если вы перезагрузите страницу, то увидите, что ничего не изменилось. А все дело в том, что загрузчик шаблонов джанго загрузит первый найденный шаблон в иерархии наследования NewAdmin. Соответственно, если у нас в settings.py приложение django.contrib.admin стоит перед нашим приложением, то NewAdmin подхватит стандартный шаблон из D:\django\hello\Lib\site-packages\django\contrib\admin\templates\admin . Спасибо за эту подсказку источнику, который, к сожалению, на момент написания статьи открывался только в мобильной версии. Надеюсь, пофиксят. Так ставим наше приложение вперед:

Перезагружаем страницу и любуемся. Мы молодцы.

В целом — скажу вам по секрету — этот путь не является оптимальным для изменения названия сайта в админке. Да. Ведь можно было просто переопределить site_header дефолтного AdminSite:

Либо вовсе переопределить весь AdminSite:

и указать его в маршрутизации:

Спасибо посту Reto Aebersold. Но последний вариант из ссылки, на мой взгляд, в большинстве проектов слишком избыточный, и его следует использовать, когда вы столкнулись с необходимостью сделать несколько раздельных админок. А зачем нам танковая артиллерия здесь? Первый вариант с переопределением admin.site.site_header — это то, что надо последовательного программирования. Но одно но… — это не то, что нам было нужно. Смысл нашего примера с переопределением шаблона — показать, как можно изменять пользовательский интерфейс админки джанго. И мы это сделали…

И это еще не все. Выше мы узнали как переопределять административные шаблоны. Теперь попробуем переопределить поля модели Profile для панели администратора. Изменим код нашего класса NewAdmin:

И в админке джанго будет отобраться только эти поля, доступные для редактирования. На этом сделаем перерыв, но это еще не все. До новой встречи

Начинаем работу с Django — изменение админки

Django admin — мощное средство, позволяющее упростить создание административной части сайта. Django автоматически создает нужные формы для создания и редактирования данных на сайте. При этом у вас может появится как минимум две причины для изменения админки — сделать ее визуально красивее и изменить формат представления данных.

Для модификации внешнего вида вы вольны использовать свои шаблоны. Также есть готовые приложения, предназначенные для этой цели — такие как Grapelli и Django Suit. Можно прочесть про их использование в статье «Улучшение админки Django«.

Также разработчики Django предоставили возможность сделать работу с объектами в базе более удобной, меняя формы и формат представляемых админкой данных.

Изменение формы добавления новых объектов

Разработчики Django выполнили за нас огромный объем работы. Вам достаточно зарегистрировать вашу модель, чтобы автоматически были созданы формы для добавления новых объектов. В случае с моделью Poll из примера регистрация выполняется командой admin.site.register(Poll), Однако часто вам понадобится изменить вид и работу административной части сайта. В том, что касается ваших моделей, это выполняется параметрами при регистрации объекта.

Давайте для примера переопределим порядок полей на форме редактирования.

Замените строку admin.site.register(Poll) таким кодом:

Все достаточно просто. Вы создаете новый класс для представления объекта в админке и затем передаете его вторым аргументом при регистрации модели.

В приведенном примере дата публикации теперь будет идти перед полем вопроса.

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

Если мы говорим о формах с сотнями полей для ввода, вы вероятно захотите разбить их, используя fieldsets:

Цукерберг рекомендует:  Создание скрытого html поля на лету

Первый элемент в каждом кортеже — заголовок fieldset. Вот как это будет выглядеть:

Вы можете назначить произвольные HTML классы любому fieldset. Django предлагает класс "collapse" который отобразит выбранный fieldset изначально свернутым. Это удобно, когда данный блок содержит данные, которые редко заполняются:

Изменение списка объектов в админке Django

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

Вот как он выглядит изначально:

По-умолчанию, Django отображает значение функции str() каждого объекта. Иногда удобнее если мы можем отобразить определенные поля. Для этого используйте list_display — кортеж с именами полей, которые в админке будут отображены в качестве столбцов на странице со списком объектов.

Вы также можете добавить любой определенный вами метод.

Теперь список наших объектов будет выглядеть в виде таблицы:

Вы можете кликнуть на заголовке столбца, чтобы отсортировать таблицу по значениям в данном столбце. Исключением являются столбцы, содержащие вывод определенных вами методов — сортировка по этим значениям не поддерживается. Также отметьте, что по-умолчанию заголовок столбца, отображающего результаты метода was_published_recently — имя метода, в котором символы подчеркивания заменены на пробелы.

Вы можете изменить поведение по-умолчанию, добавив к методу несколько атрибутов — например так:

Добавление фильтров к списку объектов

Отредактируйте файл admin.py,чтобы добавить фильтрацию. Добавьте к классу PollAdmin такую строку:

Это добавит боковую колонку с названием“Filter”, которая позволит людям отфильтровать значения таблицы по дате публикации в поле pub_date:

Вид отображаемого фильтра зависит от типа данных. Поскольку pub_date использует тип DateTimeField, Django добавит к фильтру варианты “Any date,” “Today,” “Past 7 days,” “This month,” “This year.”

Добавление поиска объектов в админке

Добавление к классу PollAdmin строки предоставит пользователям возможность поиска:

Теперь вверху списка появится поле для поиска. Когда кто-то будет вводить туда искомые значения, Django будет искать их в поле question. Вы можете задать так много полей для поиска как вам нужно.

Отображение дат

Поскольку объект Poll хранит даты, будет удобно добавить им иерархию. Добавьте строку:

Теперь наверху списка появится отображение всех лет, в которых происходила публикация. Когда вы выберете год, появятся месяцы и далее дни.

Изменение внешнего вида админки

Стандартный вариант админки Django не является образцом удобства для пользователей. Например надпись “Django administration” в верхней части каждой страницы не несет никакой полезной нагрузки — это просто кусок текста.

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

Изменение шаблонов проекта

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

Откройте файл с настройками проекта (settings.py) и добавьте параметр TEMPLATE_DIRS:

Теперь скопируйте шаблон admin/base_site.html из каталога с исходниками Django admin (django/contrib/admin/templates) в подкаталог admin, размещенный по указанному в TEMPLATE_DIRS пути. Например, если вы указали в TEMPLATE_DIRS '/path/to/mysite/templates', то скопируйте django/contrib/admin/templates/admin/base_site.html в /path/to/mysite/templates/admin/base_site.html.

Если вы не можете найти исходники Django, выполните команду:

Теперь, замените в шаблоне текст на название вашего сайта или то, что вы сочтете нужным.

Любой из стандартных шаблонов Django может быть переписан. Чтобы заменить шаблон, скопируйте его также в каталог с шаблонами вашего проекта и делайте изменения.

Учтите, что загрузчик шаблонов Django ,будет использовать первый шаблон, найденный им в файловой системе. Поэтому если вы переопределяете шаблоны, используемые административной частью сайта в вашем приложении, убедитесь, что приложение идет в списке INSTALLED_APPS раньше, чем django.contrib.admin.

Изменение основной страницы админки

Похожим образов выполняется и изменение базовой страницы админской части сайта. Стандартная индексная страница админки Django отображает все приложения из INSTALLED_APPS, которые были зарегистрированы в админке, в алфавитном порядке.

Вполне вероятно, что вы захотите изменить это — ведь главная страница очень важна и должна быть удобной в использовании. Для этого вам понадобится изменить файл admin/index.html. Перенесите его из исходников Django в ваш проект и измените. Редактируя файл, вы увидите переменную, с названием app_list. Эта переменная содержит каждое установленное в Django приложение. Вместо использования этого списка вы можете закодировать на главной странице ссылки на любые объекты, которые сочтете нужными для удобной работы.

Когда стоит применять админку Django

Django admin не очень подходит для обычных посетителей сайта. Как правило, для авторизованных посетителей, не являющихся администраторами сайта, целесообразнее создавать свои шаблоны для работы с нужной им информацией.

Использование django admin при этом вы можете оставить для администратора сайта, которому нужен простой интерфейс и возможность отредактировать любой объект в базе данных.

Блог о Django

Всякое о веб-фреймворке Django

понедельник, 11 мая 2009 г.

Действия над группой объектов в django.contrib.admin

Не так давно, в джанго-админке появились Admin Actions (http://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/#ref-contrib-admin-actions). О них я и хотел бы сегодня рассказать. В процессе записи такие действия я буду называть AdminAction .

Что это, и зачем оно мне нужно?

100 штук), не имея доступа к базе данных. Задача превращается в довольно муторную, и во всех нормальных продуктах давно уже можно пару раз жмакнуть по галочке «Выделить все» и удалить все выделенное за следующие пару кликов. Поэтому выкручивались джангисты как могли. А теперь все просто.

Смотрим как это просто

AdminAction это обычная функция, которая принимает три аргумента.

  1. Экземпляр ModelAdmin , к которому прикручено действие.
  2. HttpRequest объект, пришедший от пользователя.
  3. QuerySet выделенных объектов.

Представим, что у нас есть приложение testapp . В нем есть модель Post
Boolean -поле is_draft сигнализирует о том, что запись черновик, и публиковать ее смысла нет. Сделаем свой AdminAction , который будет публиковать выделенные посты, т.е. ставить у постов is_draft=False .

Открываем admin.py и приводим его к такому виду:

Что мы тут видим. Видим функцию make_published которая как-раз принимает те три аргумента о которых я писал выше. В PostAdmin видим строчку actions = [make_published] . Эта строчка подключает наш AdminAction к PostAdmin . Внутри функции make_published мы просто вызываем метод update у QuerySet и устанавливаем для всех выделенных объектов is_draft=False . Вот и все. Запускаем приложение и смотрим как это работает:

Логичнее было-бы, плодить новые функции внутри класса PostAdmin , и не выносить их наружу, т.к. больше они нигде не используются. Это возможно, просто перепишем наш пример следующим образом:

Что изменилось? Ну во-первых функция make_published перекочевала в PostAdmin . Во-вторых вместо первого аргумента теперь self . И в третьих в actions она указана строкой. Запускаем, и проверяем, что все работает.

Необходимые вещи

Логично было бы показывать пользователю, сколько постов реально было опубликовано при действии. Для этого мы воспользуемся методом ModelAdmin.message_user(request, message) .

Отлично. Все работает как нужно.


Интересные возможности

Помимо рассмотренного выше, есть и другие возможности, для гибкой настройки административного интерфейса.

AdminAction может возвращать объект типа HttpResponse , который будет отдан напрямую пользователю. Используя это мы можем делать экспорт моделей, сериализацию выбранных объектов в JSON , предпросмотр нескольких объектов, и вообще, все что придет нам в голову.

Включаем, выключаем

Мы рассмотрели возможность подключения AdminAction к определенному ModelAdmin . Но как могли заметить, стандартное действие удаляющее выделенные объекты, никуда при этом не делось. А что, если нам не нравится стандартный AdminAction , который позволяет удалять выделенные объекты? Это не проблема — AdminAction ‘s можно активировать и деактивировать для всего сайта в целом. Например, чтобы выключить тот самый delete_selected , мы должны написать в admin.py :
После этого, мы можем включить действие delete_selected там, где оно нужно, просто указав в списке actions у определенного ModelAdmin . А чтобы активировать наше действие, например — make_all_good для всего сайта в целом, достаточно написать:

Второй аргумент — не обязателен. Просто используя его мы сможем потом также отключить наше действие, как выше отключили delete_selected .

Чтобы выключить все действия для определенной ModelAdmin , достаточно присвоить action=None , внутри класса.

А если мы захотим иметь разный набор действий в зависимости от каких-либо условий, например от группы пользователя, то нам достаточно переопределить метод ModelAdmin.get_actions(self, request) . Который возвращает список actions .

На мой взгляд — меганужная и ожидаемая фича.

Что такое Django Framework и для чего он применяется

Сравнительно недавно программистам был представлен фреймворк Django , который использует язык программирования Python как основу. Рассказывать вам о всех преимуществах разработки сайта на данном языке нет смысла т.к. те, кто обладает знаниями питона прекрасно понимают это. Django Framework использует концепцию MVC(Model-View-Controller), что позволяет достичь высокой скорости написания кода и эффективности его работы и качественной отладке приложения.Разделяя проект на 3 части, а именно описание базы данных, внешний вид и логику работы, Django Framework становится легким в понимании каждому, даже начинающему разработчику.

Код написанный на языке Python сравнительно легок в понимании, особенно если у вас есть опыт программирования на таких языках как PHP , JavaScript и прочие.

Приведем пример кода, используемого в Django Framework, который вызывается из шаблона и позволяет заменить все пробелы в строке на знак +:

Django Framework является полностью Объектно Ориентированным, поэтому работать с ним намного приятнее (конечно для тех кто любит ООП).

В качестве модулей сайта, например, статей или новостей, Django использует специально настроенные программистом приложения, которые заточены под какие-либо нужды.

Простейшее приложение в Django состоит, как минимум из 2 файлов, а именно:
__init__.py — проще говоря, это очень важный файл, который нужен для того, что бы Python рассматривал директорию, где лежит этот файл, как приложение
views.py — логика приложения.

Как правило, файл views.py содержит в себе набор функций, которые может вызывать Django в процессе обращения к приложению.

Например нам нужно создать сайт компании, которая занимается разработкой сайтов. Создадим файл site.py (файл может иметь абсолютно любое имя) и впишем в него простейшую функцию, которая отвечает за вывод шаблона главной страницы:

В случае, если приложение подразумевает работу с базой данных, то добавляется еще один файл — models.py

С каждым днем в мире появляются все новые Django программисты! Эта система развивается, поэтому все чаще привлекает внимание профессиональных программистов.

К главным преимуществам Django Framework относится скорость создания, как легких, так и сложных проектов!

Django для того и создавался, что бы можно было разрабатывать качественные, защищенные и оптимизированные сайты в кратчайшие сроки. ;)

Расширяем возможности приложения администрирования Django

Три способа доработки этого мощного приложения для соответствия вашим нуждам

Приложение администрирования Django

Платформа Django предлагает разработчикам множество функциональности: зрелую стандартную библиотеку, активное сообщество пользователей и все преимущества языка Python. В то время как другие инфраструктуры разработки Web-приложений могут предложить то же самое, уникальным достоинством Django является ее встроенное приложение администрирования — admin.

Приложение администрирования предоставляет «из коробки» расширенную функциональность для создания, чтения, обновления и удаления данных (Create-Read-Update-Delete или CRUD), избавляя разработчиков от часов повторяющейся работы. Это является важным как при разработке Web-приложений, потому что с его помощью программисты могут быстро изучать свои модели данных, так и при развертывании приложений, потому что не имеющие отношения к технике конечные пользователи могут пользоваться приложением администрирования для добавления и редактирования содержимого сайта.

В реальной жизни всегда требуется сделать какую-либо подгонку приложения. В документации Django приводится множество руководств по преобразованию базового вида приложения администрирования, а также Django предоставляет несколько простых методов для переопределения части поведения приложения. Но что, если вам нужно больше? С чего начать? В этой статье рассказывается о нескольких направлениях, в которых можно вести серьезную переработку приложения администрирования.

Краткий обзор приложения администрирования

Возможности приложения администрирования с настройками по умолчанию знакомы большинству разработчиков Django. Сделаем краткий обзор этих возможностей. Для начала включим приложение администрирования, отредактировав файл верхнего уровня urls.py, как показано в листинге 1.

Листинг 1. Включаем приложение администрирования в urls.py
Версии ПО, используемые в этой статье
  • Django V1.0.2
  • SQLite V3
  • Python V2.4–2.6 (Django пока не поддерживает Python 3)
  • IPython (для работы в консоли)

Механизм объектно-ориентированного отображения (Object-Relational Mapper или ORM) Django поддерживает множество баз данных, среди которых проще всех в установке sqlite3. Кроме того, sqlite3 поставляется в комплекте со многими ОС. Примеры из этой статьи должны работать с любой базой данных. С полным списком баз данных, поддерживаемых Django, можно ознакомиться в разделе Ресурсы.

Django предоставляет удобный способ настройки рабочего окружения с помощью команды python manage.py shell . Во всех примерах кода, приводимых в этой статье, предполагается, что окружение настраивается именно таким образом.

В терминах Django, в этой статье предполагается следующее:

  • Проект Django называется more_with_admin.
  • В проекте more_with_admin имеется приложение с именем examples.

Приложение examples моделирует простую, похожую на блог систему документов, каждый из которых может иметь комментарии. Все примеры работы в командной строке выполняются из корневой директории проекта more_with_admin.

Также необходимо добавить приложение django.contrib.admin в кортеж settings.INSTALLED_APPS .

Перед тем как двигаться дальше, всем, кто планирует серьезно дорабатывать приложение администрирования, рекомендуется ознакомиться с его исходным кодом. Если позволяет операционная система, может быть полезным создать в директории приложения ярлык или символическую ссылку на приложение администрирования.

Приложение администрирования живет внутри пакета Django. Если вы его установили с помощью setuptools, приложение администрирования должно находиться в директории site-packages/django/contrib/admin. Ниже приводится пример создания в директории проекта символической ссылки, указывающей на исходный код приложения администрирования Django. Вы можете воспользоваться этой ссылкой, изменив ее в соответствии с вашей операционной системой и местонахождением пакета Django.

$ ln -s /path/to/Python/install/site-packages/django/contrib/admin admin-source

Метод admin.autodiscover() пробегается по всем приложениям, указанным в кортеже settings.INSTALLED_APPS и ищет файл с именем admin.py. Он обычно находится на верхнем уровне директории приложения, на одном уровне с models.py.

Приложению examples нужен файл models.py, показанный в листинге 2. Соответствующий файл admin.py приведен ниже.

Листинг 2. Пример файла models.py для этого приложения

Теперь можно запустить сервер разработки Django и взглянуть на приложение администрирования:

По умолчанию приложение администрирования доступно по адресу http://localhost:8000/admin/. Зарегистрировавшись, вы увидите главный экран администратора, показанный на рисунке 1.

Рисунок 1. Главный экран администратора Django
Изменение кода в admin.py

В отличие от остальных файлов приложения Django, если вы при работающем Web-сервере разработки Django вносите изменения в admin.py, то для вступления изменений в силу, возможно, придется вручную перезапустить сервер.

Заметьте, что модели приложения еще недоступны, потому что мы не создали файл admin.py. В листинге 3 показан код, который даст возможность работать с моделями через приложение администрирования.

Листинг 3. Пример файла admin.py

После перезагрузки основной страницы приложения администрирования, как показано на рисунке 2, новые модели становятся доступными для использования.

Цукерберг рекомендует:  Code - Не работает код(массивы)
Рисунок 2. Администратор Django готов работать с пользовательскими моделями данных

Доработка страниц моделей в приложении администрирования

Имена директорий в папках приложения администрирования

Заметьте, что я использую в именах моделей только символы в нижнем регистре. Это согласуется с тем, как работают обычные страницы администратора при генерации адресов URL. В Django эти дружественные для адресов URL имена называются «ленивыми» (slug) именами. Если вы не уверены в том, каким должно быть ленивое имя для определенной модели, перед созданием собственных директорий исследуйте приложение администрирования и посмотрите, какие имена появляются в URL-адресах.

Чтобы понять, как дорабатывать приложение администрирования не меняя исходного кода Django, важно помнить, что мы имеем дело с обычным приложением Django, таким же, как и все остальные. В первую очередь это означает, что к нему применима система наследования шаблонов Django.

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

Сначала отредактируем файл settings.py проекта, указав в нем директорию, в которой Django должен искать шаблоны (листинг 4).

Листинг 4. Добавляем в settings.py директории с шаблонами

Затем создадим в проекте следующие директории:

Приложение администрирования Django сначала попытается найти шаблоны в директории с именем, совпадающим с названием вашего приложения (здесь examples ), затем с названием моделей ( document и comment ) и только потом, в случае неудачи, будет использовать системные шаблоны для отображения страницы.

Переопределяем страницу добавления/удаления экземпляра модели

Для добавления и редактирования экземпляров модели приложение администрирования использует страницу change_form.html. Для начала создадим в директории templates/admin/examples/document/ страницу с именем change_form.html и поместим в нее следующую строку для наследования шаблона Django: <% extends "admin/change_form.html" %>.

Теперь все готово для доработки приложения. Уделите некоторое время знакомству с содержимым реального шаблона admin/change_form.html. Он довольно хорошо организован в блоки, которые можно переопределять, но в некоторых случаях доработка может потребовать «оптового» копирования блоков. Тем не менее, переопределение основанных на блоках шаблонов всегда предпочтительнее копирования страницы целиком.

Какого рода доработку можно сделать на странице добавления/редактирования? Допустим, мы хотим для каждого документа добавить предварительный просмотр пяти последних комментариев.

Сначала создадим тестовые данные(листинг 5).

Листинг 5. Создаем с помощью оболочки Django экземпляр модели Document с несколькими комментариями

Теперь в администраторе на странице списочного отображения показан один документ . Выберем этот документ, чтобы увидеть показанную на рисунке 3 страницу добавления/редактирования по умолчанию.

Рисунок 3. Стандартная страница добавления/редактирования для модели Document

Обратите внимание, что связанные с документом комментарии не показаны вообще. Обычно в приложении администрирования работа с взаимосвязанными моделями организуется посредством классов Inline . Эти мощные классы позволяют пользователям приложения администрирования редактировать или добавлять несколько взаимосвязанных моделей на одной странице. Чтобы увидеть классы Inline в действии, отредактируйте файл admin.py приложения так, как показано в листинге 6.

Листинг 6. Добавляем модель комментария к модели документов в приложении администрирования

На рисунке 4 показан новый вид страницы добавления/редактирования после добавления элемента управления TabularInline .

Рисунок 4. Страница добавления/удаления документа после добавления модели комментария в виде класса Inline

Несомненно, это мощный способ доработки приложения администрирования, однако при нем результат может оказаться слишком громоздким, тогда как мы всего лишь хотели организовать быстрый просмотр комментариев.

В таком случае имеется два подхода. Первый подход – отредактировать HTML-виджеты, ассоциированные с классами inline , с помощью предоставляемого Django интерфейса администрирования виджетов. Виджеты в документации Django описаны весьма подробно. Другой подход — модифицировать шаблон добавления/редактирования напрямую. Этот подход наиболее полезен, если вы вообще не собираетесь использовать специфическую функциональность администратора.

Если вы не хотите разрешать редактировать комментарии (например, потому что пользователи не имеют для этого достаточных прав), но вы хотите, чтобы они могли видеть комментарии, можно модифицировать шаблон change_form.html.

Переменные, предоставляемые приложением администрирования Django

Чтобы добавить функциональность на страницу отображения экземпляра модели, нужно знать, какие данные приложения администрирования уже доступны. В таблице 1 дано описание двух переменных, которые вам в этом помогут.

Таблица 1. Переменные, необходимые для доработки шаблона приложения администрирования
Переменная Описание
object_id Это первичный ключ для редактируемого объекта. Если вы дорабатываете страницу экземпляра какой-либо одной модели (например, документа), это все, что вам понадобится.
content_type_id Если вы переопределяете страницы, работающие с множеством моделей, используйте эту переменную, чтобы опрашивать инфраструктуру ContentTypes для получения имени модели. Больше информации о типах содержимого можно получить в разделе Ресурсы.

Создаем тэг шаблона и включаем его в страницу приложения администрирования

Чтобы вывести комментарии, относящиеся к документу, необходим код, который нельзя вводить непосредственно в шаблон Django. Для таких случаев наилучшим решением является использование тэга шаблона. Сначала создадим директорию тэгов шаблонов и файл __init__.py в ней:

Создадим новый файл с именем examples/templatetags/example_tags.py и добавим в него приведенный ниже код (листинг 7).

Листинг 7. Тэг шаблона для извлечения комментариев к документу с заданным >

Так как здесь используется тэг включения шаблона, необходимо создать соответствующий шаблон: comments.html. Отредактируем файл examples/templates/comments.html file и поместим в него код, показанный в листинге 8.

Листинг 8. Шаблон для предварительного просмотра комментариев

Теперь пришло время добавить это на страницу приложения администрирования. Закомментируйте в admin.py ссылки на CommentInline и сделайте в вашей локальной версии шаблона change_form.html изменения, показанные в листинге 9.

Листинг 9. Включение тэга шаблона в страницу добавления/редактирования

Перед использованием object_id надо проверять, что он существует, так как шаблон change_form.html также используется для создания новых экземпляров модели, при котором object_id экземпляра еще не доступен. Блок after_field_sets – один из многих элементов, предоставляющих возможности для расширения приложения администрирования. Остальные подобные блоки можно найти в исходном коде страницы change_form.html.

На рисунке 5 показана обновленная форма.

Рисунок 5. Страница добавления/редактирования документа после добавления на нее собственного тэга шаблона

Модифицируем поведение приложения администрирования

Как видите, одним только переопределением шаблонов можно добиться довольно многого. Но что, если мы хотим поменять само поведение приложения администрирования? Это можно сделать, подправив исходный код, но тогда вы будете ограничены только той версией Django, которую будете использовать на момент внесения исправлений.

Переопределяем методы в AdminModel

По умолчанию нажатие кнопки Save в приложении администрирования возвращает пользователя на страницу списочного отображения экземпляров модели. Обычно это всех устраивает, но что, если мы хотим переходить сразу на страницу предварительного просмотра объекта, находящуюся вне приложения администрирования? Это распространенное поведение в системах управления содержимым (content management system или CMS).

Метод

В листинге 10 предполагается, что класс Document был изменен и теперь включает в себя метод get_absolute_url() , который является рекомендуемым способом определения моделями Django своего канонического представления. Если метод определен, в администраторе Django на каждой странице этой модели также появляется полезная кнопка View on site.

Большая часть функциональности приложения администрирования реализована в классе admin.ModelAdmin . От этого класса наследуются объекты в admin.py. В нем имеется очень много публичных методов, которые можно переопределять. Определение этого класса можно посмотреть в файле admin-source/options.py.

Есть два способа поменять поведение кнопки Save: можно переопределить метод admin.ModelAdmin.response_add , отвечающий за само перенаправление после сохранения объекта, а также можно переопределить метод admin.ModelAdmin.change_view . Последний способ немного проще.

Листинг 10. Переопределяем страницу, на которую перенаправляются пользователи после сохранения документа

Теперь, когда пользователь нажимает кнопку Save, он перенаправляется на страницу предварительного просмотра сохраненного документа, а не на страницу списочного отображения всех документов.

Добавление функциональности в приложение администрирования с помощью сигналов

Сигналы – это незаслуженно мало используемая функциональность Django, улучшающая модульность вашего кода. Сигналы определяют события, такие как сохранение модели или загрузку шаблона; функции из любого места проекта Django могут узнавать о событиях и отвечать на них. Это означает, что вы можете легко расширить поведение приложения, не изменяя приложение напрямую.

В приложении администрирования имеется функциональность, которую разработчики желают поменять особенно часто – это управление пользователями с помощью класса django.contrib.auth.models.User . Часто приложение администрирования является единственным местом, где добавляются или модифицируются пользователи Django, что делает сложной доработку под себя этого полезного класса.

Представим, что мы хотим, чтобы администратор сайта получал уведомление по электронной почте каждый раз при создании нового объекта класса User . Так как модель User напрямую недоступна в проекте, может показаться, что реализовать это можно либо создав класс-наследник User , либо каким-нибудь неявным методом, например с помощью создания некого фиктивного профиля для модификации.

В листинге 11 демонстрируется, как легко добавить функцию, выполняющуюся при каждом сохранении экземпляра класса User . Сигналы обычно добавляют в models.py.

Листинг 11. Использование сигналов Django для уведомления о создании новых пользователей

Сигнал post_save предоставляется Django, он генерируется каждый раз при создании или сохранении экземпляра модели. Метод connect() здесь принимает два аргумента: функцию обратного вызова ( notify_admin ) и аргумент sender , который сообщает о том, что эту функцию следует вызывать только при сохранении экземпляров модели User .

Внутрь функции обратного вызова сигнал post_save передает отправителя (класс модели), экземпляр этой модели и булево значение, обозначающее, был ли этот экземпляр только что создан. В этом примере метод посылает электронное сообщение только при создании нового экземпляра модели User ; в противном случае не делается ничего.

В разделе Ресурсы можно ознакомиться со списком предоставляемых Django сигналов, а также с документацией по созданию собственных сигналов.

Более глубокие изменения: добавляем права строкового уровня

Почему ?

Возможно, не сразу становится понятным, почему поле ForeignKey будет выставляться с флагом blank=True , когда оно не является текстовым полем. В данном случае это так потому, что приложение администрирования использует blank вместо null , чтобы определять, должно ли значение быть выставлено вручную перед сохранением модели.

Если задать только null=True или вообще ничего, то приложение администрирования Django перед сохранением заставит пользователя вручную выбрать значение «added by», хотя вместо этого мы хотим, чтобы при сохранении по умолчанию выбирался текущий пользователь.

Для приложения администрирования Django часто дополнительно запрашивают добавление в систему прав пользователей прав строкового уровня. По умолчанию администратор обеспечивает детальное управление ролями и правами пользователей, но эти роли применяются на уровне классов: пользователь может модифицировать либо все экземпляры модели Document, либо никаких.

В ряде случаев хочется разрешить пользователям изменять только какие-либо специфичные объекты. Такие права часто называют правами строкового уровня, так как они отражают способность изменять только некоторые строки в таблице базы данных вместо права изменять любые записи в таблице без ограничений. Например, в приложении examples можно разрешить пользователям видеть только их собственные документы.

Сначала, как показано в листинге 12, добавим в models.py атрибут, в котором будет храниться имя создателя экземпляра модели Document .

Листинг 12. Добавляем в models.py информацию о пользователе, создавшем каждый экземпляр модели Document

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

Поменяем метод save_model() в файле admin.py так, как показано в листинге 13.

Листинг 13. Переопределяем метод в DocumentAdmin для сохранения текущего пользователя в базу данных при создании экземпляра модели

Если атрибут added_by равен None , значит это новая запись, которая раньше не сохранялась. (Также можно проверять, что change равно false , это обозначает, что запись добавляется, но проверка пустоты поля added_by обеспечивает, что будут заполняться и записи, которые были добавлены не из приложения администрирования.)

Далее надо ограничить список документов, доступных пользователю, только документами, созданными этим пользователем. Это можно сделать с помощью находящегося в классе ModelAdmin метода queryset() , который определяет результат запроса, по умолчанию возвращаемый любой страницей списочного отображения.

Переопределим метод queryset() так, как показано в листинге 14, чтобы ограничить список только документами, созданными текущим пользователем. Суперпользователи могут видеть все документы.


Листинг 14. Переопределяем результат запроса, возвращаемый списочными страницами

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

Конечно, на данный момент ничто не мешает находчивому пользователю получить доступ к странице редактирования чужого документа, зная его ID. По-настоящему безопасные права строкового уровня требуют переопределения большего количества методов. Так как пользователи с правами администратора, как правило, пользуются определенным доверием, иногда оказывается достаточно такой простой системы прав для обеспечения хорошо налаженного рабочего процесса.

Заключение

Для доработки приложения администрирования требуются некоторые знания исходного кода приложения, но править его приходится лишь в незначительной степени. Приложение администрирования структурировано так, чтобы быть расширяемым посредством обычного наследования Python и некоторой специфичной для Django функциональности, такой как сигналы.

Доработка под свои нужды существующего приложения администрирования имеет много преимуществ по сравнению с созданием нового интерфейса администрирования:

  • ваше приложение может выиграть от развития проекта Django по мере продолжения его активной разработки;
  • приложение администрирования уже поддерживает большинство типичных сценариев использования;
  • при добавлении в проект нового приложения оно так же, как и ваш собственный код, автоматически будет доступно для администрирования.

В Django версии 1.1 в приложении администрирования будут добавлены две часто запрашиваемые новые возможности: возможность линейного (inline) редактирования полей на страницах списочного просмотра и действия администратора (admin actions), которые позволяют обновлять за один раз множество объектов. Оба добавления устранят необходимость писать эту функциональность с нуля при расширении и доработке приложения

Ресурсы для скачивания

Похожие темы

  • Оригинал статьи: Doing more with the Django admin (EN).
  • Разработчикам, которые только начинают знакомиться с Django или приложением администрирования, следует начать с руководства Django (EN).
  • Главная страница документации приложения администрирования и исходный код приложения администрирования являются самым лучшим и полным справочником по этому приложению (EN).
  • Ознакомьтесь со списком сигналов, предоставляемых Django, и документацией по созданию собственных сигналов (EN).
  • Узнайте о двух новых возможностях приложения администрирования в Django версии 1.1: действиях администратора и редактируемых списках (EN).
  • В этой статье демонстрировалось редактирование страниц, специфичных для одной модели. Если вам нужно редактировать страницы, относящиеся к нескольким моделям, ознакомьтесь с имеющейся в Django инфраструктурой contenttypes (EN).
  • В документации Django содержится полный список баз данных, поддерживаемых Django. Начиная с версии 1.0, в Django также появилась возможность добавлять поддержку новых баз данных (EN).
  • Узнайте больше об изменении механизма перенаправления запросов в приложении администрирования (EN).
  • Многие дистрибутивы Linux®, а также Mac OS® X имеют в своем комплекте SQLite, однако если его нет в вашей системе, вы можете загрузить его с сайта проекта SQLite (EN).
  • SQLite V3: Начиная с версии 2.5, в Python появилась поддержка SQLite 3 без необходимости в дополнительных драйверах. В ранних версиях Python для этого приходилось загружать пакет pysqlite (EN).
  • Интервью и дискуссии разработчиков в подкастах developerWorks (EN).
  • Следите за developerWorks в Twitter (EN).
  • Разработайте ваш следующий проект с помощью пробного ПО от IBM, доступного для загрузки и на DVD.(EN)
  • Загрузите ознакомительные версии продуктов IBM или поработайте с онлайновой пробной версией IBM SOA Sandbox и получите практический опыт с инструментами разработки и связующим ПО от DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.(EN)

Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

Что такое Django?

Django (/ˈdʒæŋɡoʊ/ джанго) — бесплатный и свободный фреймворк для веб-приложений, написанный на Python. Фреймворк — это набор компонентов, которые помогают разрабатывать веб-сайты быстро и просто.

Каждый раз при разработке веб-сайтов требуются похожие компоненты: способ аутентифицировать пользователей (вход, выход, регистрация), панель управления сайтом, формы, инструменты для загрузки файлов и т. д.

К счастью для нас, другие люди обратили внимание на возникновение однотипных проблем при веб-разработке, так что они объединились и создали фреймворки (Django и другие), которые предлагают нам готовые шаблоны для использования.

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

Зачем нам нужен фреймворк?

Чтобы понять, для чего же нам нужен Django, нам нужно ближе познакомиться с серверами. Во-первых, сервер должен узнать о том, что мы ждём от него веб-страницу.

Представь себе почтовый ящик (порт), который проверяется на наличие новых писем (запросов). Это делает веб-сервер. Когда письмо приходит, сервер читает его и отправляет ответ с веб-страничкой. Однако чтобы что-то отправить, нам надо это что-то иметь. И Django как раз и отвечает за создание контента, который будет отправлен в ответе.

Что происходит, когда кто-то запрашивает веб-сайт у твоего сервера?

Когда на сервер приходит запрос, он переадресуется Django, который пытается сообразить, что же конкретно от него просят. Для начала он берет адрес веб-страницы и пробует понять — что же нужно сделать. Эту часть процесса в Django выполняет urlresolver (адрес веб-сайта называется URL — Uniform Resource Locator — Единый указатель ресурсов, так что название urlresolver, resolver == распознаватель, имеет определенный смысл). Он не слишком умён, поэтому просто берет список шаблонов и пытается сопоставить их с URL. Django сверяет шаблоны сверху вниз и, если что-то совпадает, он переправляет запрос соответствующей функции (которая называется view).

Представь себе почтальона с письмом. Она идет вниз по улице и сверяет номера домов с адресом на письме. Если они совпадают, то она оставляет письмо. Так же работает и urlresolver!

Но самые интересные вещи происходят в функции view: мы, например, можем обращаться к базе данных за определенной информацией. Может быть пользователь попросил изменить какую-нибудь информацию? Как будто в письме написано: «Пожалуйста, поменяйте описание моей работы.» Функция view может проверить, имеете ли вы разрешение делать это, а затем обновит описание работы и отправит обратно ответ: «Готово!». Затем функция view сгенерирует ответ, и Django сможет отправить его веб-браузеру пользователя.

В реальности все немного сложнее, однако тебе не обязательно знать все технические навороты прямо сейчас. Достаточно основной концепции.

Так что вместо погружения в пучины нюансов мы просто начнем работать с Django и познакомимся со всеми важными особенностями по мере продвижения!

Создаем свое первое веб-приложение при помощи Django

Django — это Open Source фреймворк для создания веб-приложений различной сложности. Одним из основных преимуществ Django является то, что вам нужно позаботиться только о логике вашего будущего приложения, остальное сделает Django.

Мы создадим веб-приложение, у которого будет панель администратора и возможность загружать загадки, а у пользователей, соответственно, возможность отвечать на них. Во время разработки будут использоваться Python 3.4.3 и Django 1.9.1.

Устанавливаем Django

Делается это очень просто, в командной строке нужно написать: pip install Django==1.9.1 .

Создаем проект

Если вы правильно установили Django, то после запуска django-admin —version вы увидите текущую версию фреймворка. Теперь создадим проект. Это можно сделать следующим образом: django-admin startproject django_example .

Как только создание проекта будет завершено, взглянем на директорию нашего проекта:

  • django_example/__init__.py — пустой файл, который говорит Python, что данная директория должна восприниматься в качестве пакета.
  • django_example/settings.py содержит конфигурацию нашего проекта.
  • django_example/urls.py — здесь объявляются URL.
  • django_example/wsgi.py — с помощью него приложение может работать с веб-сервером по протоколу WSGI.
  • manage.py позволяет взаимодействовать с проектом.

Теперь пришло время запустить наше приложение. Для этого в командной строке нужно написать python manage.py runserver . После этого в адресной строке браузера нужно написать: http://127.0.0.1:8000/ . Если вы увидели «You have unapplied migrations; your app may not work properly until they are applied.», то не волнуйтесь, мы вернемся к этому чуть позже.

Создаем приложение

Определим различие между проектом и приложением. Приложение — это программа, которая что-то делает, а проект — это группа приложений.

Итак, приступим к созданию приложения. Это делается следующим образом: python manage.py startapp riddles .
Как только приложение создано, давайте напишем простой вид, по правилам Django все виды должны храниться в файле views.py .

Теперь, чтобы привязать наш вид к URL, создадим файл urls.py .

В urls.py мы должны написать следующее:

Теперь, если мы запустим наше приложение http://127.0.0.1:8000/riddles/ , мы увидим «Hello, World!».

Установка базы данных

По умолчанию в Django используется SQLite, если она вас не устраивает, то вы можете ознакомиться с нашей статьей, в которой мы рассказываем, как безболезненно перейти с SQLite на MySQL.

4 октября 2020 – 1 марта 2020, Москва и онлайн, беcплатно

Теперь откроем django_example/settings.py и взглянем на переменную INSTALLED_APPS , она хранит все приложения, которые активны в текущем проекте. По умолчанию она содержит:

  • django.contrib.admin — админка, скоро мы ей воспользуемся.
  • django.contrib.auth — система аутентификации.
  • django.contrib.contenttypes — фреймворк для content types.
  • django.contrib.sessions — сессионный фреймворк.
  • django.contrib.messages — фреймворк для отправки сообщений.
  • django.contrib.staticfiles — фреймворк для работы со статичными файлами.

Некоторые из этих приложений используют базы данных, но они еще не установлены, поэтому мы и видели «You have unapplied migrations; your app may not work properly until they are applied.». Поправить это можно следующим образом: python manage.py migrate . Вы должны увидеть следующее:

Теперь создадим нашу модель. Для начала создадим Riddle и Option . В Riddle будет содержаться загадка, в Option — один из возможных ответов на нее.

Данная модель обеспечивает Django информацией, необходимой для создания схемы базы данных и database-access API для доступа к объектам. Теперь нам нужно привязать наше приложение к нашему проекту, делается это следующим образом:

После этого нужно сделать миграцию: python manage.py makemigrations riddles . Вы должны увидеть следующее:

Так мы говорим Django, что в моделях были сделаны некоторые изменения, и их нужно сохранить в качестве миграции.

Проверить, что сделает миграция, можно так: python manage.py sqlmigrate riddles 0001 (0001 — версия миграции, которую мы хотим проверить). На выходе мы получим:

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

Теперь мы можем начать пользоваться панелью администратора. Но для этого нам нужен пользователь. Создать его можно следующим образом: python manage.py createsuperuser . После этого запускаем сервер, если он не запущен, и переходим на http://127.0.0.1:8000/admin/ . Вы увидите следующее:

Теперь дадим админу возможность изменять наши модели. Делается это так:

Вот что получится в итоге:

Возьмите небольшую паузу и поиграйтесь с панелью администратора. Вы будете приятно удивлены тем, что умеет Django.

Главная страница

Что нам нужно для создания главной страницы?

  • Templates: скелет нашей страницы.
  • Views: функция на Python для отображения контента.

Начнем с шаблонов. Создадим папку templates внутри папки riddle , а в ней создадим index.html .

Теперь создадим макет для ответов:

Здесь мы используем csrf_token , он нужен для защиты от межсайтовой подделки запроса, каждая внутренняя форма должна его использовать. Теперь напишем виды для рендеринга наших шаблонов:

Давайте пройдемся по каждой функции отдельно:

  • index: Index использует функцию render . На вход она получает HttpRequest, местонахождение шаблона и его содержимое, а возвращает HttpResponse с окончательным html.
  • detail: Detail делает практически то же самое, но только функция get_object_or_404 возвращает HttpResponse404, если нужный объект не был найден.
  • answer: Answer ищет предоставленную загадку (и возвращает 404, если она не найдена) и проверяет правильность ответа.

Теперь добавим наши функции в urls.py :

Добавим немного стилей

Для начала создадим директорию static , а в ней создадим файл main.css .

Немного изменим наши шаблоны:

Первая строка загружает статические файлы, потом мы используем <% static '#' %>, где # — путь к вашему файлу. Аналогичная процедура проводится и для JavaScript.

Теперь вы можете создавать свои собственные приложения на Django.

Исходный код нашего приложения можно скачать по этой ссылке.

Начинаем работу с Django — подключение админки

На предыдущем шаге нами заданы структуры данных для хранения списка вопросов и вариантов ответов для них.

Пока мы еще ничего не сделали для того, чтобы иметь возможность работать с данными через сайт. Но Django предосставляет нам мощную систему администрирования для управления данными нашего сайта прямо из коробки. Админка Django не предназначена для обычных посетителей сайта. Скорее это средство, упрощающее для администратора работу с данными. Django автоматически создает интерфейс для управления нашими данными на базе созданных нами моделей также, как создает соотвествующие им таблицы в базе данных.

Включение админки Django

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

Во-первых, в файле настроек проекта settings.py нужно раскоментировать строку django.contrib.admin

Теперь нам снова нужно выполнить команду

Django создаст в базе данных таблицы, которые необходимы для работы админской части сайта.

Теперь нужно отредактировать файл mysite/urls.py, чтобы сообщить Dajngo, какой код нужно вызвать, когда мы обратимся через браузер к админке.

Для этого раскоментируем нужные строки. Теперь файл mysite/urls.py должен выглядеть так:

Строки, которые нужно раскоментировать, подсвечены жирным шрифтом.

Для запуска нашего сайта выполним команду

В консоли вы должны увидеть

Это означает, что все в порядке, и мы можем начинать работу с сайтом. Но вместо http://127.0.0.1:8000/ откроем http://127.0.0.1:8000/admin/

Вы должны увидеть приглашение ввести логин и пароль для входа в админку Django

Входим в админку, используя указанные на первом шаге логин и пароль супер-пользователя.

Создание суперпользователя админки Django

Если по какой-то причине вы не создали суперпользователя раньше, то вы можете это сделать, выполнив консоли команду

Зайдя в админку, вы должны увидеть подобную картину:

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

Отображение объектов в админке Django — подключаем наши модели

Чтобы получить доступ к изменению объектов через админ. часть сайта, нужно зарегистрировать их в приложении admin.

Создайте новый файл в каталоге polls с названием admin.py. В файл вставьте следующий текст:

Теперь перезапустите сервер и обновите или зайдите заново в админку.

Порядок! Теперь нам доступно создание и редактирование новых вопросов через пункт Polls.

Django автоматически формирует веб-форму на базе модели, которая позволяет ввести все нужные данные. При этом еще не будет введено какое-то из полей, отмеченных как обязательное, форма вернет нас к редактированию подсветив нужные поля для ввода:

После заполнения всех полей и сохранения объекта, информация о нем сохраняется в базе данных.

Новый объект появился в списке, однако выглядит не очень информативно:

Дело в том, что для вывода информации об объекте Django использует метод __unicode__(). В созданном нами классе Poll нет такого метода. Добавим его.

Добавление названия объектам

Для вывода информативного названия объекта, добавим метод __unicode__() к классам Poll и Choice.

Отредактируем models.py, добавив выделенный жирным текст:

Теперь после обновления списка объектов Poll в админке используется текст, который мы ввели в качестве вопроса:

Добавление связанных объектов

Чтобы можно было добавить новые варианты ответов через админку, достаточно в файле admin.py добавить:

Теперь “Choices” появилась в Django admin. При добавлении нового варианта ответа нужно будет выбрать соответствующий вопрос:

Однако это не очень удобно. В списке выбора вопроса будут все вопросы, которые были сохранены в базе. Кроме того, логично вводить варианты ответов при добавлении вопроса.

Давайте сделаем это.

В файле admin.py уберем register() для класса Choice и отредактируем регистрацию класса Poll. Измените текст на приведенный ниже.

Теперь объекты Choice могут быть добавлены сразу при добавлении вопроса, при этом Django предложит заполнить сразу 3 варианта, а при необходимости добавить новые.

Единственный момент — класс admin.StackedInline выводит все поля друг под другом и этом занимает много места. В Django admin есть более подходящий класс TabularInline для табличного вывода полей.

Дополнительную информацию по изменеию админки Django можно найти в статье http://itman.in/django-admin-changes/

А нам пора позаботиться о том, что будут отображать основные страницы нашего сайта. Переходим дальше.

Начинаем работу с Django — подключение админки: 9 комментариев

Здравствуйте. После попытки добавить новый «poll» в админке — получаю ошибку:
«»»
no such table: polls_poll

Request Method: POST
Request URL: http://127.0.0.1:8000/admin/polls/poll/add/
Django Version: 1.8.4
Exception Type: OperationalError
Exception Value:
no such table: polls_poll
«»»
К какому из этапов урока мне нужно вернуться?

Виталий, если вы описали модели в models.py, то возможно ві забыли добавить ваше приложение (в случае описанных уроков оно называется polls) в INSTALLED_APPS.

Посмотрите внимательно вывод выполнения команды
python manage.py syncdb
в http://itman.in/django-howto/#_Django-4

Если дело в этом — просто добавьте приложение в список и выполните
python manage.py syncdb повторно.

Чтобы лучше разобраться с работой Django с базами данных и как можно менять таблицы базы после ее создания — рекомендую прочесь http://itman.in/django-db-migration/.

Но это потом, на первом этапе лучше просто удалить базу и создать заново, пока все не будет получаться :)

Была такая же проблема. Оказалось, что начиная с какой-то версии (1.7 или 1.8) команда syncdb удалена, вместо нее необходимо использовать:
python manage.py makemigrations
python manage.py migrate

python manage.py makemigration
python manage.py migrate

Возникла та же проблема, что и у Виталия

OperationalError at /admin/polls/poll/add/
no such table: polls_poll

Не знаю в чём проблема, везде всё прописано и синхронизировано

Попробуй:
python manage.py makemigrations
python manage.py migrate
python manage.py syncdb

Потом restart server

У меня __unicode__ не заработал, пришлось заменить на __str__

Цукерберг рекомендует:  Можно ли обойтись без антивируса Осваиваем работу в виртуальной машине
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих