Что такое Джанго? Краткое руководство по Django, часть 1

Что такое Django?

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

Фреймворк Django Framework

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

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

Django

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

Проект Django

Django был разработан

Django app

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

Django Models

Модели в Django - это классы, которые определяют, какие таблицы и столбцы создаются в базе данных. Когда вы обращаетесь к базе данных через ORM (Object Relational Mapping) Django, вы получаете экземпляры вашего класса Model и можете получить доступ к данным через поля, которые вы определили в этой модели. Взаимодействие с экземпляром модели приводит к чтению и записи в базу данных и из нее. Узнать больше о моделях можно здесь.

Django Views

Виды находятся между тем, что видит пользователь, когда заходит в ваш проект Django из браузера, и данными, которые находятся в вашей базе данных. Представление принимает веб-запрос и возвращает веб-ответ обратно в браузер. Представление - это место, где живет логика "что мы хотим вернуть на этот конкретный запрос?". По умолчанию, Django Views возвращает HttpRequests, но они могут возвращать JSON, HTML, XML, вложения или все, что вы хотите - если это содержится в объекте Response.

Исторически, Django Views были просто функциями, и вы были в основном предоставлены сами себе при их написании. Теперь в Django есть целый набор Generic Class-Based Views, которые вы можете настроить и использовать прямо из коробки. Они охватывают большинство представлений, которые могут понадобиться вам в любом приложении, и поскольку это классы Python, они также наследуются и расширяются. Ознакомьтесь с ними здесь.

Шаблоны Django

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

Учебник Django

Для этого руководства я буду использовать Django 2.1.7 и Python 3.6.7. Вы можете получить доступ к коду из этого руководства на github-репозитории Kite.

Давайте подготовим почву для веселого проекта Django!

Вот история: вы и ваши друзья - энтузиасты импровизации и любите Whose Line is it Anyway и музыкальные стили Уэйна Брэди. Вы хотите создать проект Django, который вы сможете использовать для игры Whose Line Is It Anyway на вашей следующей импровизационной вечеринке.

Давайте рассмотрим сценарий (или историю пользователя), чтобы изложить требования.

"Как участники вечеринок Improv, мы хотим получить произвольные сцены, чтобы разыграть их"

Про совет: Пользовательские истории - это часть Agile-разработки, которая позволяет вам представить, как пользователь будет использовать ваше приложение, и помогает определить требования к продукту. Рассматривайте истории как разговор о том, что один человек хочет или нуждается в вашем приложении.

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

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

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

Теперь, когда у нас есть virtualenv для нашего проекта, давайте установим Django:

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

Теперь у вас есть проект Django, который содержит каталог корневого уровня для проекта, а внутри него утилиту Django manage.py и пакет Python, который имеет то же имя, что и ваш проект, и содержит ваш файл Django settings.py, корневой urls.py файл и wsgi.py файл.

Тот факт, что проект и подкаталог имеют одинаковое имя, всегда немного смущал меня, поскольку этот подкаталог не является настоящим приложением Django и просто содержит настройки для всего проекта Django.

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

Далее, давайте создадим приложение Django в нашем проекте. Использование команды django-admin startapp автоматически создает файловую структуру и добавляет модули-шаблоны для приложения Django. Важными для нас сегодня являются models.py и views.py. Остальные мы будем использовать позже, а также добавим несколько своих собственных, чтобы придать этому проекту мурлыканье.

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

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

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

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

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

Я использую PyCharm с включенной поддержкой Django, поэтому PyCharm сможет увидеть, какие файлы шаблонов проиндексированы, и указать, когда они отсутствуют или находятся в неправильном месте при ссылке на них в представлении. Это удобная функция, когда вы пытаетесь отладить, почему ваше представление выдает ошибки. (Не волнуйтесь, такое случается.)

Поскольку я уже упоминал о пространствах имен, я расскажу о них более подробно. Из The Zen of Python: "Пространства имен - это одна замечательная идея - давайте делать их больше!".

Я согласен с этим утверждением, потому что пространства имен помогают устранить двусмысленность в коде, поэтому я добавил `scenes` к имени нашего шаблона, потому что это говорит мне, из какого приложения этот шаблон. В Django у вас может быть много приложений, и у этих приложений может быть много шаблонов; даже если у вас всего несколько приложений, вы наверняка будете пересекаться в том, как вы хотите назвать свои шаблоны. Именование шаблонов dir помогает вам - и Django - знать, какой шаблон вам нужен, когда вы его назначаете.

Вернемся к нашему приложению.

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

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

Про совет: В PEP8 говорится, что константы должны быть написаны всеми заглавными буквами, с подчеркиванием, разделяющим слова. [https://www.python.org/dev/peps/pep-0008/#constants]

Заглянув внутрь TemplateView, мы видим, что он возвращает объект context в отрисованный шаблон. В нашем SceneView, который наследуется от TemplateView, мы можем добавить get_context_data и в него, а также super в родительский класс, чтобы получить его контекст. Затем мы добавляем наши собственные данные в словарь контекста, которые передаются в render_to_response и, наконец, попадают в шаблон, возвращаясь в виде TemplateResponse.

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

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

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

И точно так же наш шаблон теперь случайным образом выбирает одну из наших сцен и возвращает ее при загрузке страницы.

Успех! Вы только что создали свой первый проект Django! Он простой, но он работает.

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

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

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

Вернуться на верх