Веб-фреймворк Django (Python)
Django является чрезвычайно популярным и полнофункциональным серверным веб-фреймворком, написанным на Python. Данный модуль расскажет о том, почему Django один из самых популярных серверных веб-фреймворков, как установить среду разработки, и как начать использовать его для создания собственных веб-приложений.
Требования
Перед началом работы с этим модулем вам не обязательно уже быть знакомым с Django. Вам бы пригодилось общее понимание того, что такое серверное веб-программирование и веб-фреймворки, почерпнутое, в идеале, из топиков другого нашего модуля Первые шаги серверного программирования веб-сайтов.
Рекомендуется базовое понимание концепций программирования и языка Python, но это не обязательно для освоения основных понятий.
Примечание: Python является одним из самых доступных в чтении и понимании для новичков языком программирования. Тем не менее, если вы захотите глубже понять этот модуль, в Интернете сейчас доступны многочисленные бесплатные книги и учебные пособия (новички в программирование возможно захотят посетить Python for Non Programmers на вики-страницах python.org).
Руководство
Задания
Следующее задание проверит ваше понимание того, как создать сайт с помощью Django, как описано в руководствах, перечисленных выше.
DIY Django мини-блог В этом задании вы будете использовать некоторые знания, которые вы узнали из этого модуля, чтобы создать свой собственный блог.
Django что такое приложения
Веб-приложение или проект Django состоит из отдельных приложений. Вместе они образуют полноценное веб-приложение. Каждое приложение представляет какую-то определенную функциональность или группу функциональностей. Один проект может включать множество приложений. Это позволяет выделить группу задач в отдельный модуль и разрабатывать их относительно независимо от других. Кроме того, мы можем переносить приложение из одного проекта в другой независимо от другой функциональности проекта.
При создании проекта он уже содержит несколько приложений по умолчанию.
Список всех приложений можно найти в проекте в файле settings.py в переменной INSTALLED_APPS :
И, конечно, мы можем создавать свои приложения, которые реализуют определенный функционал. Так, создадим в проекте, созданном в прошлой теме или новом, первое приложение. Для этого выполним в командной строке/терминале следующую команду:
Рассмотрим вкратце его структуру:
папка migrations : хранит информацию, которая позволяет сопоставить базу данных и определение моделей
__init__.py : указывает интерпретатору python, что текущий каталог будет рассматриваться в качестве пакета
admin.py : предназначен для административных функций, в частности, здесь призводится регистрация моделей, которые используются в интерфейсе администратора
apps.py : определяет конфигурацию приложения
models.py : хранит определение моделей, которые описывают используемые в приложении данные
tests.py : хранит тесты приложения
views.py : определяет функции, которые получают запросы пользователей, обрабатывают их и возвращают ответ
Но пока приложение никак не задействуется. Его надо зарегистрировать в проекте Django. Для этого откроем файл settings.py и добавим в конец массива INSTALLED_APPS наше приложение:
В проекте может быть несколько приложений, и каждое из них надо добавлять таким вот образом.
Теперь определим какие-нибудь простейшие действия, которые будет выполнять данное приложение, например, отправлять в ответ пользователю строку «Hello World».
Эффективный Django. Часть 1
Оглавление
Введение ⇧
«Связный» код — это код, который сосредоточен на выполнении одной вещи, только одной единственной вещи. Это значит, что когда вы пишете функцию или метод — написанный вами код должен делать что-то одно и делать это хорошо.
Это непосредственно относится к написанию тестируемого кода: код, который делает много вещей, достаточно часто является чересчур сложным для тестирования. Когда я ловлю себя на мысли: «Хорошо, этот кусок кода слишком сложен, чтобы писать для него тесты — это просто не стоит потраченных усилий» — вот сигнал к тому, чтобы вернутся назад и сосредоточиться на упрощении. Тестируемый код — такой код, который позволяет просто писать для него тесты; код, в котором легко найти проблемы.
И наконец, мы хотим писать масштабируемый код. Это означает не просто масштабировать его в терминах исполнения, но так же увеличивать в терминах команды и командного понимания. Хорошо протестированные приложения проще для понимания другими (и проще для изменения ими), что подразумевает большую возможность улучшить ваше приложение, путем добавления новых инженеров.
Моя цель — убедить вас в важности этих принципов, и предоставить примеры того, как следуя им, построить более стойкое Django-приложение. Я собираюсь последовательно пройти через процесс построения приложения для управления контактами, рассказывая про решения и стратегию тестирования, которые я использую.
Эти документы являются сочетанием заметок и примеров подготовленных для PyCon 2012, PyOhio 2012, и PyCon 2013, а также для web-разработки Eventbrite. Я все еще работаю над объединением их в один документ, но надеюсь вы найдете их полезными.
Примеры кода для этого руководства доступны на github’е. Отзывы, предложения и вопросы можете присылать на nathan@yergler.net.
Этот документ доступен на сайте, а также в форматах PDF и EPub.
Видео этого руководства с PyCon можно посмотреть на YouTube.
Глава 1. Приступая к работе ⇧
1.1. Ваша среда разработки
Изоляция означает, что вы не сможете случайно воспользоватся инструментами или пакетами установленными вне вашего окружения. Это особенно важно, когда подобное происходит с чем-то, похожим на пакеты Python с расширениями написанными на C: если вы используете что-то установленное на системном уровне и не знаете об этом, то при развертывании или распространении своего кода вы можете обнаружить, что он работает не так как предполагалось. Инструменты наподобие virtualenv могут помочь создать нечто похожее на изолированную среду.
Ваша среда предопределена, если вы уверены в том, на какую версию ваших зависимостей вы полагаетесь и сможете ли вы наверняка воспроизвести системное окружение.
1.1.1. Изоляция
1.1.2. Предопределенность
1.1.3. Сходство
1.2. Настройка вашего окружения
1.2.1. Создание чистого рабочего пространства
Примечание переводчика:
Для начала создадим каталог ( tutorial ), в котором будем работать:
В каталоге venv будет находится наше виртуальное окружение, а в каталоге project — Django-проект
1.2.2. Создание файла зависимостей
Создайте файл requirements.txt в директории tutorial с единственной строкой (зависимостью) в нем:
Примечание переводчика:
В случае, если вы хотите использовать последнюю версию Django (1.7 — на момент написания перевода) — вместо строки Django==1.6.7 оставьте просто Django — pip установит последнюю доступную версию.
1.2.3. Установка зависимостей
А теперь мы можем использовать pip для установки зависимостей:
1.3. Начало проекта Django
Когда здание находится в процессе постройки, строительные леса часто используются для поддержания структуры до того как строительство будет завершено. Строительные леса могут быть временными или они могут служить частью фундамента здания, но несмотря на это, они представляют некоторую поддержку когда вы только начинаете работу.
Django, как и многие web-фреймворки, представляет скаффолдинг для вашей разработки. Это происходит при помощи принятия решений и предоставления отправной точки для вашего кода, что позволяет вам сосредоточится на проблеме, которую вы пытаетесь решить, а не на том, как разобрать HTTP-запрос. Django предоставляет скаффолдинг как для работы с HTTP, так и для работы с файловой системой.
1.3.1. Создание проекта
Созданный проект имеет следующую структуру
1.3.2. Скаффолдинг проекта
1.3.3. Создание приложения
Созданное приложение имеет следующую структуру:
Примечание переводчика:
На текущий момент наша директория
/tutorial/ содержит файл зависимостей ( requirements.txt ), директорию с виртуальным окружением ( venv/ ), один проект ( project/addressbook ), одно приложение ( project/contacts ) и имеет следующее содержание:
Глава 2. Используем модель ⇧
2.1. Конфигурирование базы данных
Для использования SQLite нам нужно указать движок ( ENGINE ) и имя базы ( NAME ). SQLite интерпертирует имя базы как имя файла для базы данных:
2.2. Создание модели
Модели Django отображают (грубо говоря) таблицы базы данных, и предоставляют место для инкапсулирования бизнес-логики. Все модели являются наследниками базового класса Model и содержат поля определений. Давайте создадим простую модель Contacts для нашего приложения в файле contacts/models.py :
После того, как вы создали модель, необходимо дополнить вашу базу данных новыми таблицами. Команда Django syncdb смотрит установленные модели и создает (если нужно) таблицы для них:
Примечание переводчика:
Django предложит создать суперпользователя для андминки, которая включена в этой версии по умолчанию. Воспользуйтесь его предложением.
Примечание переводчика:
Если вы используете Django версии 1.7 и выше — вывод будет следующий:
Однако нашей таблицы с контактами нигде не видно. Причина этого состоит в том, что нам нужно еще указать проекту использовать приложение.
После этого запустите syncdb снова:
Примечание переводчика:
Для Django версии 1.7 и выше вам нужно будет запустить сначала команду makemigrations — для создания миграций на основе изменений в моделях, а после этого выполнить команду migrate — для того чтобы применить созданные миграции.
Примечание переводчика:
Вывод для Django 1.7 и выше:
Заметьте, что Django создает таблицу с именем contacts_contact : по умолчанию Dj ango дает таблицам имена используя комбинацию имени приложения и имени модели. Вы можете изменить это с помощью опций модели Meta.
2.3. Взаимодействие с моделью
Теперь, когда модель синхронизирована с базой данных мы можем взаимодействовать с нею используя интерактивную оболочку:
Здесь использовалось несколько новых штук. Во-первых, команда manage.py shell запускает для нас интерактивную оболочку Python’а с правильно установленными путями для Django. Если вы попробуете запустить интерпретатор Python и просто импортировать ваше приложения, будет выброшено исключение, потому что Django не знает, какие настройки использовать, и не может отобразить экземпляры модели на базу данных.
2.4. Написание тестов
Вы можете запустить тесты для вашего приложения используя команду manage.py test :
Если вы запустите это, то увидите что выполнилось около 420 тестов. Это удивляет, так как мы написали только один. Произошло это потому, что по умолчанию Django запускает тесты для всех установленных приложений. Когда вы добавляли приложение contacts в наш проект, то могли увидеть, что там по умолчанию были добавлены несколько встроенных приложений Django. Дополнительные 419 тестов были взяты оттуда.
Примечание переводчика:
В нашем случае (при использовании версии Django 1.6.7) предыдущий абзац несколько устарел: запустится только один тест — тот который мы создали. Вывод команды будет такой как указано ниже.
Если же вы захотите запустить тесты для определенного приложения — укажите имя приложения в команде:
2.5. Резюме
Примечание переводчика:
Для того чтобы протестировать наше, пока еще пустое, приложение нужно выполнить следующую команду:
Это запустит встроенный сервер, функционал которого любезно предоставляет нам Django. В параметрах после runserver указывается ip-адрес и порт, который будет слушаться работающим сервер. В нашем случае сервер будет принимать запросы от всех ip-адресов при обращении на 8080 порт.
Создаем своё первое веб-приложение с помощью Django
Авторизуйтесь
Создаем своё первое веб-приложение с помощью Django
Django — это Open Source фреймворк для создания веб-приложений различной сложности. Одним из основных преимуществ Django является то, что вам нужно позаботиться только о логике вашего будущего приложения, остальное сделает Django.
Мы создадим веб-приложение, у которого будет панель администратора и возможность загружать загадки, а у пользователей, соответственно, возможность отвечать на них. Во время разработки будут использоваться Python 3.4.3 и Django 1.9.1.
Устанавливаем Django
Создаем проект
Как только создание проекта будет завершено, взглянем на директорию нашего проекта:
Создаем приложение
Определим различие между проектом и приложением. Приложение — это программа, которая что-то делает, а проект — это группа приложений.
27–28 ноября, Москва, Беcплатно
В urls.py мы должны написать следующее:
Установка базы данных
По умолчанию в Django используется SQLite, если она вас не устраивает, то вы можете ознакомиться с нашей статьей, в которой мы рассказываем, как безболезненно перейти с SQLite на MySQL.
Данная модель обеспечивает Django информацией, необходимой для создания схемы базы данных и database-access API для доступа к объектам. Теперь нам нужно привязать наше приложение к нашему проекту, делается это следующим образом:
Так мы говорим Django, что в моделях были сделаны некоторые изменения, и их нужно сохранить в качестве миграции.
Проверить, что сделает миграция, можно так: python manage.py sqlmigrate riddles 0001 (0001 — версия миграции, которую мы хотим проверить). На выходе мы получим:
Заметьте, что команда sqlmigrate нужна только для проверки, каждый раз ее запускать необязательно.
Теперь дадим админу возможность изменять наши модели. Делается это так:
Вот что получится в итоге:
Возьмите небольшую паузу и поиграйтесь с панелью администратора. Вы будете приятно удивлены тем, что умеет Django.
Главная страница
Что нам нужно для создания главной страницы?
Теперь создадим макет для ответов:
Давайте пройдемся по каждой функции отдельно:
Теперь добавим наши функции в urls.py :
Добавим немного стилей
Немного изменим наши шаблоны:
Первая строка загружает статические файлы, потом мы используем <% static '#' %>, где # — путь к вашему файлу. Аналогичная процедура проводится и для JavaScript.
Теперь вы можете создавать свои собственные приложения на Django. В качестве подсказки на старте работы с фреймворком воспользуйтесь одной из наших шпаргалок по Python.
Исходный код нашего приложения можно скачать по этой ссылке.
Если этот проект показался сложным, попробуйте пройти двухчасовой видеокурс. На нём вы пошагово создадите 3 веб-приложения: сокращатель ссылок, ToDo List и словарь английских слов.
Приложения ¶
Этот реестр называется apps и доступен в django.apps :
Проекты и приложения ¶
Термин « приложение» описывает пакет Python, который предоставляет некоторый набор функций. Приложения могут быть повторно использованы в различных проектах.
Приложения включают в себя некоторую комбинацию моделей, представлений, шаблонов, тегов шаблонов, статических файлов, URL-адресов, промежуточного программного обеспечения и т. Д. Они обычно связаны с проектами с INSTALLED_APPS настройкой и, необязательно, с другими механизмами, такими как URLconfs, MIDDLEWARE настройка или наследование шаблонов.
Нет никаких ограничений, что пакет проекта не может также рассматриваться как приложение и иметь модели и т. Д. (Что потребовало бы его добавления INSTALLED_APPS ).
Настройка приложений ¶
Если AppConfig подкласс не найден, AppConfig будет использоваться базовый класс.
В качестве альтернативы INSTALLED_APPS может содержать пунктирный путь к классу конфигурации, чтобы явно указать его:
Для авторов приложений ¶
Если вы создаете подключаемое приложение под названием «Рок-н-ролл», вы можете указать собственное имя для администратора следующим образом:
Вы можете предоставить несколько AppConfig подклассов с различным поведением. Чтобы указать Django, какой из них использовать по умолчанию, установите default значение True в его определении. Если ваши пользователи хотят выбрать конфигурацию, отличную от конфигурации по умолчанию, они должны заменить ‘rock_n_roll’ путь с точками к этому конкретному классу в своих INSTALLED_APPS настройках.
В предыдущих версиях default_app_config переменная в модуле приложения использовалась для определения класса конфигурации приложения по умолчанию.
Для пользователей приложения ¶
В этой ситуации INSTALLED_APPS должен содержать пунктирный путь к классу конфигурации, поскольку он находится вне приложения и, следовательно, не может быть обнаружен автоматически.
Конфигурация приложения ¶
Объекты конфигурации приложения хранят метаданные для приложения. Некоторые атрибуты можно настроить в AppConfig подклассах. Остальные устанавливаются Django и доступны только для чтения.
Настраиваемые атрибуты ¶
Этот атрибут определяет, к какому приложению применяется конфигурация. Он должен быть установлен во всех AppConfig подклассах.
Он должен быть уникальным для проекта Django.
Краткое название приложения, например ‘admin’
Он должен быть уникальным для проекта Django.
Удобочитаемое имя приложения, например «Администрация».
В большинстве случаев Django может автоматически определять и устанавливать это, но вы также можете предоставить явное переопределение в качестве атрибута класса для своего AppConfig подкласса. В некоторых ситуациях это требуется; например, если пакет приложения является пакетом пространства имен с несколькими путями.
Установите для этого атрибута значение, False чтобы Django не выбирал класс конфигурации автоматически. Это полезно, когда apps.py определяется только один AppConfig подкласс, но вы не хотите, чтобы Django использовал его по умолчанию.
Установите для этого атрибута значение, True чтобы сообщить Django о необходимости автоматического выбора класса конфигурации. Это полезно, когда apps.py определяется более одного AppConfig подкласса, и вы хотите, чтобы Django использовал один из них по умолчанию.
По умолчанию этот атрибут не установлен.
Неявный тип первичного ключа, добавляемый к моделям в этом приложении. Вы можете использовать его в AutoField качестве типа первичного ключа для сторонних приложений.
Атрибуты только для чтения ¶
Методы ¶
Возвращает итерацию Model классов для этого приложения.
Требуется, чтобы реестр приложений был полностью заполнен.
Возникает, LookupError если в этом приложении нет такой модели.
Подклассы могут переопределить этот метод для выполнения задач инициализации, таких как регистрация сигналов. Он вызывается, как только реестр будет полностью заполнен.
В обычном процессе инициализации ready метод вызывается Django только один раз. Но в некоторых угловых случаях, особенно в тестах, которые возятся с установленными приложениями, ready может вызываться более одного раза. В этом случае либо напишите идемпотентные методы, либо установите флаг для ваших AppConfig классов, чтобы предотвратить повторный запуск кода, который должен выполняться ровно один раз.
Пакеты пространств имен как приложения ¶
Пакеты Python без __init__.py файла известны как «пакеты пространства имен» и могут быть распределены по нескольким каталогам в разных местах sys.path (см. PEP 420 ).
Приложениям Django требуется единый путь к базовой файловой системе, где Django (в зависимости от конфигурации) будет искать шаблоны, статические ресурсы и т. Д. Таким образом, пакеты пространства имен могут быть приложениями Django, только если выполняется одно из следующих условий:
Реестр приложений ¶
Реестр приложений предоставляет следующий общедоступный API. Методы, которые не перечислены ниже, считаются частными и могут быть изменены без предварительного уведомления.
Логический атрибут, значение которого устанавливается True после полного заполнения реестра и вызова всех AppConfig.ready() методов.
Возвращает итерацию AppConfig экземпляров.
apps. get_app_config ( app_label ) ¶
apps. is_installed ( имя_приложения ) ¶
Возникает, LookupError если такого приложения или модели не существует. Возникает ValueError при вызове с одним аргументом, который не содержит ровно одной точки.
Процесс инициализации ¶
Как загружаются приложения ¶
При запуске Django django.setup() отвечает за заполнение реестра приложения.
Настраивает Django с помощью:
Эта функция вызывается автоматически:
В других случаях он должен вызываться явно, например, в простых скриптах Python.
Если это класс конфигурации приложения, Django импортирует корневой пакет приложения, определенный его name атрибутом. Если это пакет Python, Django ищет конфигурацию приложения в apps.py подмодуле или создает конфигурацию приложения по умолчанию.
На этом этапе ваш код не должен импортировать никаких моделей!
Другими словами, корневые пакеты ваших приложений и модули, которые определяют классы конфигурации вашего приложения, не должны импортировать какие-либо модели, даже косвенно.
По завершении этого этапа API-интерфейсы, которые работают с конфигурациями приложений, например, get_app_config() становятся пригодными для использования.
Затем Django пытается импортировать models подмодуль каждого приложения, если он есть.
По завершении этого этапа API-интерфейсы, работающие с такими моделями, get_model() становятся пригодными для использования.
Наконец, Django запускает ready() метод каждой конфигурации приложения.
Устранение неполадок ¶
Вот некоторые общие проблемы, с которыми вы можете столкнуться во время инициализации:
AppRegistryNotReady : Это происходит, когда при импорте конфигурации приложения или модуля моделей запускается код, зависящий от реестра приложения.
Выполнение запросов к базе данных с помощью ORM во время импорта в модулях моделей также вызовет это исключение. ORM не может работать должным образом, пока не будут доступны все модели.
Это исключение также происходит, если вы забыли вызвать django.setup() автономный скрипт Python.
Чтобы устранить такие проблемы, вам следует свести к минимуму зависимости между модулями моделей и выполнять как можно меньше работы во время импорта. Чтобы избежать выполнения кода во время импорта, вы можете переместить его в функцию и кэшировать ее результаты. Код будет выполнен, когда вам впервые понадобятся его результаты. Эта концепция известна как «ленивая оценка».