Создание браузера на django
Джанго это мощный фреймворк для создания веб-приложений. Изначально Django был создан для того, чтобы быстро создавать, например, новостные сайты (или другие сайты, который нужно создавать максимально быстро). И после нативного PHP не покидает ощущение, что ты едешь на очень быстрой машине разработки. Чтобы посмотреть все его возможности для быстрой разработки, мы с вами попробуем создать простое Todo — приложение.
Начнем с формулировки краткого т.з. У нас будет небольшое веб-приложение с версткой на Bulma (да, я очень люблю Bulma. Возможно, когда-нибудь я сверну на Bootstrap или Picnic, но всему свое время). У нас (пока) нет авторизаций и пользователь может создавать, редактировать и удалять либо категорию дел, либо карточку todo, которая связана с какой-либо категорией, которую создал пользователь. Todo карточку или категорию можно удалить, поставив галочку на checkbox и нажав кнопку удалить.
Основные концепции Django
Немного поговорим о Django. Django реализует архитектурный паттерн MVT (Модель Представление Шаблон), которая немного отличается от знакомого большинству MVC (Модель Представление Контроллер) на котором работает Ruby on Rails и Laravel.
Модель (Model) Модель в Django описывает схему данных в БД. С Django ORM, вы можете самостоятельно описывать поля и любые другие типы данных, и совершать миграции для упрощения разработки.
Шаблон Шаблон в Django это простой HTML код со специальным шаблонным языком Django. DTL (Django Template Language) — это язык, с помощью которого вы можете динамически менять содержимое страницы (к примеру, изменять имя пользователя на странице, в зависимости от того, как зовут авторизовавшегося пользователя).
Настройки Файл настроек в Django, в котором находятся все настройки вашего веб-приложения. Он включает в себя секретный ключ, папки с шаблонами, middlewares (которые отвечают, например за то, чтобы ваши приватные альбомы не увидели другие пользователи), подключение к базе данных, и много всего остального.
Url Файл настройки роутинга — примерно то же самое, что и в Angular или Laravel. Это связывает представление с url запросами.
Установка Python и Django
Автор этой статьи (то есть я) кроме написания статей занимается еще и обучением основам питона детей. По долгу службы я ставил Python и его пакеты на достаточно большое количество разнообразных машин. И кроме переустановок питона, один раз для установки пакета глобально сработал даже даунгрейд версии языка. Да, так тоже бывает.
Версии Python
До последнего времени активно поддерживались и развивались две основные ветки Python: 2.7 и 3.x. Я буду использовать версию 3.7.3 в данной статье, но на самом деле это не так важно. Если вы правда хотите знать разницу между ними, есть специальная вики. С другой стороны, сейчас уже нет никакого смысла использовать Python версии 2.7 — обновление языка остановилось на 2.7.17 (если я правильно понимаю документацию на официальном сайте). Это означает, что есть смысл переводить проекты написанные на Python 2.7.x на новую ветку, а вот новые писать на 2 версии совсем бессмысленно.
Инсталляция Python
Если вы работаете на Mac или Ubuntu — у вас уже скорее всего установлен Python, однако 2 версии. Python третьей версии придется скачивать отдельно, и вызывать его в командной строке вы сможете через python3. В любом случае, лучше всего скачать последний релиз здесь.
Создание своего виртуального окружения
На самом деле первое приложение на Django вы можете начать разрабатывать и не создавая свое виртуальное окружение, однако навык создания виртуального окружения может пригодится если вы, например, разрабатываете приложение с определенной версией библиотеки и не хотите устанавливать библиотеки глобально и замусоривать ваш system.
Так как же использовать virtual env?
1) Самый простой вариант. Вы можете скачать замечательный IDE от JET BRAINS PyCharm Community Edition отсюда. После установки PyCharm создайте новый проект, и Pycharm по умолчанию предложит вам создать Virtual Env, в котором будет возможность установить нужную версию Django (или по умолчанию последнюю, которая на момент написания данной статьи 3.0.2):
2) Чуть более хардкорный вариант:
А что, если вы хотите запустить Django в virtual env, к примеру, в любимой папке?
Во, первых, создаем папку, в которой мы будет творить:
Дальше вводим следующие команды для активации venv, где django_env имя нашего виртуального окружения:
Далее наше виртуальное окружение активировалось. Можем поставить необходимые пакеты. В нашем случае это Django:
Если вы захотите выключить виртуальное окружение, чтобы вернуться в ваш глобальный python (вернуться в контекст system), введите следующую команду:
Хорошо, надеюсь с виртуальным окружением мы разобрались. Если возникли какие-то проблемы и дополнительные вопросы, полезные ссылочки можно найти здесь и здесь .
Создание самого проекта
Допустим вы выбрали какой-то из способов создания своего виртуального окружения (или даже делаете все глобально, что же, никто не запрещает вам это делать). Теперь проходим в папку проекта и начинаем его создание:
Так, после того как Django открыл стартовую страницу, необходимо проинсталлировать наше приложение todolist в основное приложение. Открываем settings.py и добавляем в уже имеющийся список приложений наш собственный todolist:
Следующим шагом будет связывание приложения с базой данных. Если базы данных — это не то, с чем вы хотите возиться, вам стоит воспользоваться решением по умолчанию — SQlite. Я же решил воспользоваться PostgreSQL — она популярна и классически связана с Django, кроме того, потом мы можем захотеть увеличить производительность приложения. Инструкций как устанавливать PostgreSQL на все операционные системы достаточно много. Я разрабатываю под MacOS и не без небольших танцев с бубном я поставил эту базу данных, скачав сам Postgres.app отсюда . Что касается интерфейсов для БД, то здесь я воспользовался Postico и пробной версии для разработки приложения нам вполне хватит (хотя в принципе можно обойтись и без неё, потому что все наше взаимодействие с базой данных будет построено через само веб-приложение и миграции). Кроме того, пришлось поставить psycopg2 в виртуальное окружение проекта (без этого драйвера с БД ваше приложение работать не будет).
Дальше нужно настроить работу статики. По-прежнему редактируем файл settings.py , теперь в самом конце добавляем работу со статикой:
Для того, чтобы у вас заработала статика, проверьте что в списке INSTALLED_APPS находился пакет, отвечающий за статику:
django.contrib.staticfiles, на тот случай, если произойдет ошибка.
И последнее в подготовительных работах, нам нужно ещё настроить базовую работу url в проекте:
Я добавил редирект так как хочу, чтобы с дефолтной страницы localhost сразу переходил на подстраницу category(чтобы не дай бог пользователь не потерялся). Также у нас есть роутинг на две страницы: категорий и дел.
Итак, надеюсь ваше приложение не упало. Далее мы можем наконец-то переходить к созданию самого приложения:
Создание модели Todo и Категорий
Дальше приступим к созданию модели, которая будет базово взаимодействовать с нашей базой данных. Для создания модели открываем файл models.py в нашем todolist и начинаем творить. Начнем с того, что создадим таблицу категорий:
Отлично! Да, здесь у нас будет только две колонки в таблице Категорий: id и name. Дальше создадим таблицу для наших дел. Думаю, из комментариев все понятно:
После того, как ваша модель будет готова, необходимо создать миграции:
И потом запускаете сами миграции:
Создание view
Откроем файл view.py в todolist и отредактируем его. Для начала добавим необходимые импорты и редирект с главной на category:
Потом начинаем создание нашего дела. У экземпляра дела будут поля самого текста, даты, до которой должно быть закончено дело, категория дела, и объединенный контент:
После этого добавим функции добавления и удаления дел:
С тудушками все. Дальше можем перейти к странице Категорий. Создаем функцию категорий, в которой у нас тоже будет функция добавления и удаления категории. Принципиально здесь ничего нового не будет, у нас так же здесь будет возможность добавления и удаления:
На этом мы заканчиваем с файлом view и можем переходить к шаблонам:
Работа с шаблонами
Как вы помните, чтобы не писать css лишний раз, я воспользовался bulma.css для упрощения верстки. Т.к. наши страницы категорий и todo буду очень схожи, я создал три файла:
base.html , который будет включать в себя все одинаковое, что у нас есть на страницах, а в category.html , todo.html будут располагаются отличия:
Создаем base.html и редактируем его:
Дальше у нас пойдут страницы todo.html и category.html :
И category.html . В ней у нас не особо много чего меняется, принципиально никак не отличается от todo.html :
Всем спасибо! На этом все. Возможно, где-то не идеальна верстка, или есть другие предложения по улучшению приложения, всех жду в комментарии. По традиции, несколько полезных ссылок:
Встроенная система аутентификации Django очень хороша и безопасна. Ее можно использовать, не меняя ни строчки кода, что экономит силы на разработку и тестирование. Стандартной функциональности хватает для большинства случаев.
Но иногда случается, что в нее нужно внести некоторые изменения, чтобы она подходила вашему веб-приложению: возможно, вам необходимо сохранить дополнительные данные пользователя, например, краткое описание или местоположение.
В этой статье мы сравним различные способы расширения стандартной модели пользователя в Django.
Способы расширения существующей модели пользователей
Существует четыре разных способа расширения существующей модели пользователя, о которых пойдет речь в статье:
- использование прокси-модели;
- использование связи один-к-одному с пользовательской моделью;
- создание модели пользователя с помощью расширения класса AbstractBaseUser ;
- создание модели пользователя с помощью расширения класса AbstractUser .
Для начала вам необходимо определиться, какой из способов подходит вам больше всего.
Использование прокси-модели
Прокси-модель — это модель, отнаследованная от существующей модели без создания новой таблицы в базе данных. Она используется для изменения поведения существующей модели, например, задания сортировки по умолчанию или добавления новых методов, не затрагивающих схему базы данных.
Когда следует использовать прокси-модель?
Прокси-модель используется для расширения существующей модели пользователя, когда в базе данных не нужно хранить дополнительную информацию, а нужно добавить базовой модели дополнительные методы или изменить ее Manager , управляющий запросами к базе данных.
Это то, что мне нужно! Перейти к коду!
Использование связи один-к-одному с пользовательской моделью
В этом случае создается обычная модель Django, у которой будет собственная таблица базы данных и которая будет одна-к-одной связана с существующей моделью пользователя через OneToOneField .
Когда следует использовать связи один-к-одному?
Связь один-к-одному используется, когда нужно хранить дополнительную информацию о существующей модели пользователей, которая не связана с процессом аутентификации. Такую модель обычно называют профилем пользователя.
Это то, что мне нужно! Перейти к коду!
Создание модели пользователя через расширение AbstractBaseUser
Это совершенно новая модель пользователя, которая наследуется от AbstractBaseUser . Ее грамотная интеграция требует дополнительных усилий и обновления некоторых связей через settings.py . При выборе этого варианта настоятельно рекомендуется провести все манипуляции с моделями до начала работы над проектом, так как это повлияет на всю схему базы данных. Использование этого способа в готовом проекте может вызвать проблемы при внедрении новой модели.
Когда следует использовать этот способ?
Использование пользовательской модели нужно тогда, когда приложение имеет особые требования к процессу аутентификации. Например, если вам нужно использовать адрес электронной почты вместо имени пользователя.
Это то, что мне нужно! Перейти к коду!
Создание модели пользователя через расширение AbstractUser
Этот способ также подразумевает создание новой модели пользователя, но которая наследуется уже от AbstractUser . Здесь актуальны все те же замечания, что и для пункта выше: необходимость дополнительных усилий для внедрения и обновления некоторых связей через settings.py , сложности при интеграции в готовый проект.
Когда следует использовать этот способ?
Используется только тогда, когда вас вполне устраивает, как работает аутентификация в Django и вы ничего не хотите в ней менять, но тем не менее, вам нужно добавить дополнительную информацию непосредственно в пользовательскую модель ( User ), причем без создания дополнительного класса (как в варианте с прокси-моделью).
Это то, что мне нужно! Перейти к коду!
Расширение модели пользователя через прокси-модель
Это один из самых простых способов расширить существующую модель пользователя. Используя этот способ, вы избежите сложностей, но будете сильно ограничены.
Вот как это можно сделать:
В приведенном выше примере создается прокси-модель с именем Person . Тот факт, что она является прокси-моделью, указывается внутри класса Meta : proxy = True .
Сама прокси-модель в этом примере используется для переопределения сортировки по умолчанию, назначения нового Manager и определения нового метода do_something .
Отметим, что User.objects.all() и Person.objects.all() будут обращаться к одной и той же таблице базы данных. Единственное различие заключается в поведении, которое определяется для прокси-модели. Вот и все.
Расширение модели пользователя с помощью связи один-к-одному
Вероятно, этот метод и есть то, что вам нужно, потому что именно его используют чаще всего. Мы создадим новую модель для хранения дополнительной информации о пользователе.
Стоит понимать, что использование этой стратегии приводит к дополнительным запросам или объединениям для получения связанных данных. По сути, когда создается запрос к связанным данным, Django делает дополнительный запрос. Но этого можно избежать в большинстве случаев. Мы к этому вернемся чуть позже.
Обычно в Django такие модели называют Profile :
А теперь установим сигналы для Profile на автоматическое создание/обновление, когда мы создаем/обновляем стандартную модель пользователя ( User ):
Как можно видеть, основная нагрузка — это добавление вызовов create_user_profile и save_user_profile всякий раз, когда происходит сохранение (в том числе создание) объекта. Этот вид сигнала называется post_save .
Дадим еще несколько поясняющих примеров. Можно использовать следующий код в шаблоне:
Или такой внутри представления:
Вообще говоря, вам никогда не придется вызывать метод сохранения профиля. Все делается методами User .
Отдельно обсудим вопрос использования форм. Можно использовать более одной формы сразу. Как в этом примере:
А теперь о дополнительных запросах к базе данных.
Django будет формировать запрос к базе данных только при доступе к одному из связанных свойств. Иногда это вызывает нежелательные эффекты, такие как запуск сотен или тысяч запросов. Этот эффект можно смягчить, используя метод select_related .
Зная заранее, что вам нужно будет получить доступ к связанным данным, вы можете предварительно выбрать их в одном запросе к базе данных:
Расширение модели пользователя с помощью наследования AbstractBaseUser
Это самый сложный вариант, старайтесь избегать его любой ценой. Однако иногда это невозможно.
Допустим, нам нужно использовать адрес электронной почты в качестве логина и использование username совершенно бесполезно. Также у нас нет необходимости в использовании флага is_staff , поскольку мы не будем использовать админку Django.
В таком случае пользовательскую модель можно определить так:
В коде все сделано так, чтобы сохранить новую пользовательскую модель как можно ближе к существующей модели пользователя. Поскольку мы наследуем от AbstractBaseUser , нужно определить несколько свойств и методов:
- USERNAME_FIELD — строка, описывающая имя поля в модели пользователя, которая используется как идентификатор. Поле должно быть уникальным (то есть иметь значение unique=True , установленное в его определении);
- REQUIRED_FIELDS — список имен полей, которые будут запрашиваться при создании пользователя через команду управления createsuperuser;
- is_active — логический атрибут, указывающий, является ли пользователь активным;
- get_full_name() — более длинный формальный идентификатор для пользователя. В этом примере будем использовать полное имя пользователя, но это может быть любая строка, которая идентифицирует пользователя;
- get_short_name() — короткий «неофициальный идентификатор» пользователя. В нашем примере — имя пользователя.
Также нужно определить UserManager . Это связано с тем, что существующий менеджер определяет методы create_user и create_superuser .
А вот как выглядит UserManager , удовлетворяющий перечисленным выше требованиям:
Он удаляет существующий UserManager , а также имя пользователя и свойство is_staff .
Теперь последний шаг. Нужно обновить settings.py , а именно свойство AUTH_USER_MODEL :
Таким образом мы даем понять, что нужно использовать нашу собственную модель вместо стандартной. В приведенном выше примере была создана пользовательская модель внутри приложения с именем core .
Как ссылаться на эту модель? Есть два пути. Рассмотрим модель с названием Course :
В коде все отлично, но если вы создаете многоразовое приложение, которое хотите сделать доступным для сообщества, настоятельно рекомендуется использовать следующую стратегию:
Расширение модели пользователя с помощью наследования AbstractUser
Здесь все довольно просто, поскольку класс django.contrib.auth.models.AbstractUser обеспечивает полную реализацию пользователя по умолчанию как абстрактную модель:
Затем вам как и в предыдущем способе нужно обновить settings.py , определяя свойство AUTH_USER_MODEL :
Это нужно сделать перед началом работ над проектом, так как это повлияет на всю схему базы данных. Также старайтесь создавать внешние ключи для модели пользователя, импортируя параметры из from django.conf import settings и ссылаясь на settings.AUTH_USER_MODEL вместо прямого обращения к новой пользовательской модели.
Выводы
В статье мы рассмотрели четыре разных способа расширения существующей модели пользователя. Самого лучшего универсального варианта среди них нет, так что вам придется выбирать наиболее подходящий в зависимости от того, чего вы хотите добиться.
Джанго — это Open Source фреймворк для создания веб-приложений различной сложности на Python. Одним из его основных преимуществ является то, что вам нужно позаботиться только о логике будущего веб-приложения, остальное сделает 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 позволяет взаимодействовать с проектом.
Пишем веб-приложение на Django
Определим различие между проектом и приложением. Приложение — это программа, которая что-то делает, а проект — это группа приложений.
Итак, приступим к созданию приложения. Это делается следующим образом: python manage.py startapp riddles .
Как только создано веб-приложение, напишем вид, по правилам Джанго все виды должны храниться в файле views.py .
Теперь, чтобы привязать наш вид к URL, создадим файл urls.py .
В urls.py мы должны написать следующее:
Установка базы данных
По умолчанию в Django используется SQLite, если она вас не устраивает, то вы можете ознакомиться с нашей статьей, в которой мы рассказываем, как безболезненно перейти с SQLite на MySQL.
Теперь откроем django_example/settings.py и взглянем на переменную INSTALLED_APPS , она хранит все приложения, которые активны в текущем проекте. По умолчанию она содержит:
Данная модель обеспечивает Django информацией, необходимой для создания схемы базы данных и database-access API для доступа к объектам. Теперь нам нужно привязать наше приложение к нашему проекту, делается это следующим образом:
После этого нужно сделать миграцию: python manage.py makemigrations riddles . Вы должны увидеть следующее:
Так мы говорим Django, что в моделях были сделаны некоторые изменения, и их нужно сохранить в качестве миграции.
Проверить, что сделает миграция, можно так: python manage.py sqlmigrate riddles 0001 (0001 — версия миграции, которую мы хотим проверить). На выходе мы получим:
Заметьте, что команда sqlmigrate нужна только для проверки, каждый раз ее запускать необязательно.
Теперь дадим админу возможность изменять наши модели. Делается это так:
Вот что получится в итоге:
Возьмите небольшую паузу и поиграйтесь с панелью администратора. Вы будете приятно удивлены тем, что умеет Джанго.
Главная страница
Что нам нужно для создания главной страницы?
- Templates: скелет нашей страницы.
- Views: функция на Python для отображения контента.
Начнем с шаблонов. Создадим папку templates внутри папки riddle , а в ней создадим index.html .
Здесь мы используем csrf_token , он нужен для защиты от межсайтовой подделки запроса, каждая внутренняя форма должна его использовать. Теперь напишем виды для рендеринга наших шаблонов:
Давайте пройдемся по каждой функции веб-приложения на Django отдельно:
Теперь добавим наши функции в urls.py :
Стили
Для начала создадим директорию static , а в ней создадим файл main.css .
Немного изменим наши шаблоны:
Теперь вы можете создавать свои веб-приложения на Django. В качестве подсказки на старте работы с фреймворком воспользуйтесь одной из наших шпаргалок по Python.
Исходный код нашего приложения можно скачать по этой ссылке.
Если этот веб-проект на Django показался сложным, попробуйте пройти двухчасовой видеокурс. На нём вы пошагово создадите 3 веб-приложения: сокращатель ссылок, ToDo List и словарь английских слов.
Создаём проект Django в виртуальном окружении Python
Создайте новую папку и перейдите в неё:
mkdir django-react && cd $_
Потом активируйте виртуальное окружение Python:
Примечание все следующие команды нужно выполнять из папки django-react и с активированным виртуальным окружением.
Установите зависимости Джанго и Django REST Framework:
pip install django djangorestframework
После установки создайте новый проект Django:
django-admin startproject django_react
Теперь сделаем API на Django для создания и хранения контактов.
Пишем приложение с бэкендом на Django
В каждом проекте Django может быть много приложений. Приложения можно делать переиспользуемыми: такими, что их можно добавить в менеджер пакетов Python и установить через него в другой проект, в котором нужно такое приложение.
Для создания нового приложения Django используется команда:
django-admin startapp app_name
где app_name — название приложения.
В нашем случае команда будет выглядеть так:
django-admin startapp leads
Она создаст приложение leads в папке django-react . Теперь структура папок в проекте должна выглядеть так:
Теперь сделаем так, чтобы Django проект использовал новое приложение. Откройте файл django_react/settings.py и добавьте приложение в INSTALLED_APPS :
Создаём модель в базе данных с Джанго
Модель — это объект, представляющий собой данные из таблицы. Почти каждый веб-фреймворк использует модели, и Django — не исключение. Она может иметь одно или больше полей. Каждое поле соответствует полю в таблице.
Мы собираемся хранить контакты, поэтому модель Lead может состоять из этих полей:
Добавим ещё поле со временем создания модели, потому что по умолчанию Django этого не делает.
Откроем leads/models.py и опишем модель Lead :
Примечание изучите документацию Django о полях. Когда придумываете структуру модели, выбирайте самые подходящие для вашего случая поля.
Создадим миграции командой:
python manage.py makemigrations leads
и применим их к базе данных:
python manage.py migrate
Займёмся тестированием
Вы могли подумать «А как же тестирование?».
Существует масса туториалов по бэкенду на Джанго, начинающихся примерно так:
Не надо так. Нет никакого смысла ни в тестировании стандартной модели Django, ни в тестировании Django ORM. Что точно не нужно тестировать при создании приложения с бэкендом на Django:
- встроенный код Django (модели, представления);
- встроенные функции Python.
Не тестируйте то, что уже протестировано! Так что же тогда тестировать?
Добавили свой метод в модель Django — протестируйте его. Дополнили стандартное представление — протестируйте его. Но как узнать, что именно нужно протестировать?
Узнать это поможет библиотека coverage. Установите её:
pip install coverage
Теперь после каждого добавления или изменения кода запускайте coverage :
coverage run --source='.' manage.py test
и создавайте отчёт:
Вы увидите, что именно нужно протестировать. Если предпочитаете увидеть отчёт в командной строке, запустите команду:
Сериализаторы Django
Сериализация — это конвертация объекта Python в другой формат. После сериализации можно сохранить объект в файл или послать его через сеть.
Почему сериализация необходима? Модель Джанго — это класс Python. Чтобы превратить её в данные в формате JSON, нужна сериализация.
Сериализаторы работают и в обратном направлении: они конвертируют JSON в объекты. Это позволяет:
- отображать модель Django в браузере с помощью конвертации в JSON;
- делать запросы CRUD (create — read — update — delete) к API в формате JSON.
Суммируя: сериализаторы в Django можно использовать для совершения операций с моделями Django через API.
Создайте новый файл leads/serializers.py . Сериализатор LeadSerializer содержит нашу модель и поля:
Созданный дочерний класс от класса serializers.ModelSerializer . ModelSerializer в Django похож на ModelForm . Он подходит, когда нужно, чтобы сериализатор соответствовал модели.
Создаём представления
Если вы раньше работали с другими фреймворками, то можете удивиться, что в Django нет контроллеров.
Django — это фреймворк MVT. MVT — это модель, представление и шаблон (Template). В Django есть много типов представлений: функции-представления, представления, основанные на классах, и обобщённые представления.
Используйте функции-представления только если изменение обобщенных представлений займет больше, чем написание представления заново.
Мы будем использовать обобщённые представления. Наше простое приложение будет:
- возвращать выборку моделей;
- создавать новые объекты в базе данных.
С помощью документации можно узнать, что есть представление для возвращения выборки и создания моделей: ListCreateAPIView . Это представление содержит queryset и serializer_class .
queryset — это выборка данных, которую приложение будет возвращать. В нашем случае — все модели Lead . serializer_class — класс сериализатора для модели.
Добавьте в файл django_react/views.py следующий код:
С помощью трёх строк кода мы создали представление для обработки GET и POST запросов.
Чего ещё не хватает? Маршрутизации URL. Другими словами, нам нужно соединить URL и представления.
Настраиваем маршрутизацию url
Нам нужно сделать так, чтобы GET и POST запросы к api/lead/ обрабатывались представлением LeadListCreate , которое будет возвращать и создавать модели.
Чтобы настроить маршрутизацию URL, отредактируйте файл django_react/urls.py , добавив туда url приложения:
Так мы указываем в бэкенде на Django, что нужно использовать url, которые есть в приложения leads .
Теперь создайте файл leads/urls.py . В нём мы соединим представление LeadListCreate и url api/lead/ :
И наконец, включим rest_framework в INSTALLED_APPS . Откройте django_react/settings.py и добавьте приложение в INSTALLED_APPS :
Запустим сервер Django:
python manage.py runserver
Примечание в продакшене лучше отключить возможность просмотра API. Это можно сделать в конфигурации:
Соединяем Django и React
У многих разработчиков возникают вопросы по поводу того, как правильно соединить Django и React.
Данная статья предназначена для новичков в web-программировании и освещает вопросы разработки блога на Django с использованием Twitter Bootstrap и его развертывания на бесплатном хостинге PythonAnywhere. Я старался написать как можно более проще и понятнее. Более опытным пользователям данное чтиво не расскажет ничего нового, да и некоторые приемы возможно покажутся неэффективными.
Cоздаем и активируем окружение:
В ОС Windows последняя команда должна быть такой:
Устанавливаем Django с помощью pip — менеджера пакетов Python.
Создаем новый проект. Назовем его как-нибудь оригинально — например mysite.
Скрипт отработает и создаст каталог mysite с еще одним каталогом mysite и несколькими *.py файлами внутри.
Используем скрипт manage.py для создания приложения django с именем blog.
Отредактируем настройки в файле mysite/settings.py (обратите внимание: я имею ввиду ~/projects/mysite/mysite/settings.py) добавив туда следующее:
В первой строке укажем кодировку в которой работаем, во избежание путаницы и глюков предлагаю указывать ее во всех изменяемых файлах *.py, перекодируя их соответственно в UTF-8.
В BASE_DIR будет храниться полный путь к нашему проекту, что бы использовать относительные пути при дальнейшем конфигурировании
Настроим базу данных, в нашем проекте вполне можно использовать SQLite
Настроим часовой пояс и язык:
Для того что бы Django узнало о созданном приложении, добавим 'blog' в кортеж INSTALLED_APPS, а также раскомментируем строку 'django.contrib.admin' для включения встроенной админки:
Чтобы админка заработала, редактируем mysite/urls.py
Cоздаем модель в blog/models.py
На основании этой модели Django автоматически создаст таблицы в базе данных.
Регистрируем ее в админке blog/admin.py
Создадим таблицы командой:
При первом вызове этой команды Django предложит создать суперпользователя, воспользуемся данным предложением.
Запускаем отладочный сервер который предоставляет Django:
Теперь вводим url в браузере
Если все прошло хорошо, мы должны видеть это:
Заходим с ранее созданным логином\паролем в админку — теперь мы имеем возможность добавлять и удалять посты (кнопки справа от Posts)
Создадим несколько постов для отладки.
Теперь займемся созданием фронтенда, нам требуется всего две шаблонных страницы — одна с перечислением всех постов, вторая — содержание поста.
Добавим в urlpatterns mysite/urls.py строку
Для того что бы все URL-ы начинающиеся с /blog/ будут обрабатываться с помощью urls.py из модуля blog, и создаем сам файл urls.py в каталоге blog со следующим содержанием:
Теперь нужно создать шаблоны страниц. По умолчанию для класса PostListView Django будет искать шаблон в blog/templates/blog/post_list.html (такой длинный и странный путь связан с логикой работы фреймворка, в силах разработчика поменять это поведение, но в данной статье я этого не касаюсь)
создадим этот файл:
Добавим возможность комментирования наших записей, в этих целях мы воспользуемcя услугами DISQUS, который установим с помощью pip
Этот модуль предоставляет функционал комментариев, с защитой от спама, аватарками и прочим, а также берет на себя заботу по их хранению:
Добавляем в post_detail.html перед
В INSTALLED_APPS файла settings.py добавляем 'disqus'
А также добавляем в settings.py
Тестируем проект в браузере. Отлично, функционал нашего приложения внушает, но надо что-то делать с оформлением. Самый простой, и в тоже время современный вариант, использовать Twitter Bootstrap.
Редактируем settings.py, что бы Django знало где искать статические страницы.
Создаем файл blog/templates/blog/base.html следующего содержания
Это основной шаблон для наших страниц, включаем его в post_list.html и post_detail.html дописав первой строкой в них
Проверяем работоспособность. Вот теперь красота наведена, можно приступить развертыванию приложения на бесплатном облачном хостинге.
Регистрируем бесплатный N00b аккаунт на PythonAnywhere. Мне понравился этот сервис легкостью в установке Django, все происходит практически так же как и на локальном компьютере.
Меняем в settings.py
Закачиваем файлы на хостинг любым из доступных способов.
На мой взгляд, для неискушенного пользователя, проще всего заархивировать папку проекта, залить архив на сервер (в разделе Files->Upload a file) и разархивировать его на сервере командой в bash — шелле (Раздел Consoles -> bash):
например если мы залили файл mysite.tar.gz то выполняем в консоли PythonAnywhere
Настраиваем статические страницы в разделе Web -> Static files:
В первой строке — место где лежит bootstrap, во второй статические файлы встроенной админки Django.
Настраиваем WSGI (Web -> It is configured via a WSGI file stored at: . ):
Читайте также: