Советы для джанго

Создание моделей¶

Теперь, после создания окружения (проекта), мы можем приступить к работе.

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

Проекты или приложения

Какая разница между приложением и проектом? Приложение – это Web-приложение, которое предоставляет определенный функционал – например, Web-блог, хранилище каких-то записей или простое приложение для голосования. Проект – это совокупность приложений и конфигурации сайта. Проект может содержать несколько приложений. Приложение может использоваться несколькими проектами.

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

Создавая приложение, убедитесь, что вы находитесь в том же каталоге, что и файл manage.py, и выполните команду:

$ python manage.py startapp polls

Эта команда создаст каталог polls:

polls/
    __init__.py
    admin.py
    migrations/
        __init__.py
    models.py
    tests.py
    views.py

Эти файлы являются частью приложения голосования.

Первый шаг в создании Web-приложения с БД в Django – это создание его моделей, которые являются, по сути, схемой базы данных с дополнительными метаданными.

Философия

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

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

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

Эти понятия отображаются простыми классами Python. Отредактируйте файл polls/models.py, чтобы он выглядел таким образом:

polls/models.py

from django.db import models


class Question(models.Model):
    question_text = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')


class Choice(models.Model):
    question = models.ForeignKey(Question)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=)

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

Каждое поле представлено экземпляром класса – например, для текстовых полей и для полей даты и времени. Это указывает Django какие типы данных хранят эти поля.

Названия каждого экземпляра (например, question_text или pub_date ) это название поля, в “машинном”(machine-friendly) формате. Вы будете использовать эти названия в коде, а база данных будет использовать их как названия колонок.

Вы можете использовать первый необязательный аргумент конструктора класса , чтобы определить отображаемое, удобное для восприятия, название поля. Оно используется в некоторых компонентах Django, и полезно для документирования. Если это название не указано, Django будет использовать “машинное” название. В этом примере, мы указали отображаемое название только для поля Question.pub_date. Для всех других полей будет использоваться “машинное” название.

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

может принимать различные необязательные аргументы; в нашем примере мы указали значение для votes` равное 0.

Нас Django вкус волнует и манит

Прошло уже несколько недель, как официально вышла 3 версия Django. Я работал с этой версией ещё до публикации официального релиза и, к сожалению, заметил, что развитие Django сильно замедлилось. Версия 1.3 от 1.7 отличается в разы, а вот 3 версия содержит косметические изменения ветки 2 и не более.
Мой проект winePad стартовал с версии Django 1.3, и к текущему моменту в нем переопределено около 12% внутреннего кода Django.
Видя код новой версии, я понимаю, что правки, которые я или мои коллеги сделали при работе с предыдущими версиями поедут и дальше. А глядя на roadmap и вялотекущие изменения официального репозитория ждать, что ошибки будут скорректированы в будущих версиях — не приходится.
Вот о работе над ошибками я и хочу рассказать:

Как искать вакансии Django-программисту

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

На удаленку лучше переходить более опытному и дисциплинированному программисту, а не новичку

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

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

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

Это возможно! Создадим HTML-файл , у которого будет заголовок с ссылками на две созданные нами страницы. Название для файла можно выбрать любое, в данной случае просто стало традицией. Теперь закрываем веб-сервер и затем создаем новый файл.

Shell

(pages) $ touch templates/base.html

1	(pages)$touchtemplatesbase.html

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

Для добавления URL-ссылок в проект мы можем использовать , который присваивает себе имя URL паттерна в качестве аргумента. Помните, как мы добавляли опциональные URL названия двум адресам в ? Это было сделано именно по этой причине. Тег использует эти названия для автоматического создания ссылок.

URL путь для нашей домашней страницы был назван , поэтому для настройки ссылки к ней мы будем использовать: .

Python

<!— templates/base.html —>
<header>
<a href=»{% url ‘home’ %}»>Home</a> | <a href=»{% url ‘about’ %}»>About</a>
</header>

{% block content %}
{% endblock content %}

1 2 3 4 5 6 7

<!—templatesbase.html—> <header> <ahref=»{% url ‘home’ %}»>Home<a>|<ahref=»{% url ‘about’ %}»>About<a> <header> {%block content%} {%endblock content%}

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

Python

<!— templates/home.html —>
{% extends ‘base.html’ %}

{% block content %}
<h1>Homepage</h1>
{% endblock content %}

1 2 3 4 5 6

<!—templateshome.html—> {%extends’base.html’%} {%block content%} <h1>Homepage<h1> {%endblock content%}

и

Python

<!— templates/about.html —>
{% extends ‘base.html’ %}

{% block content %}
<h1>About page</h1>
{% endblock content %}

1 2 3 4 5 6

<!—templatesabout.html—> {%extends’base.html’%} {%block content%} <h1>Aboutpage<h1> {%endblock content%}

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

Неплохо, правда?

Домашняя страница с заголовком

Страница «About» с заголовком

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

Что нового в Django 3.2 ¶

Автоматическое обнаружение

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

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

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

С автоматическим обнаружением больше не требуется. Как следствие, он устарел.

См. Подробную информацию в разделе « .

Настройка типа автоматически создаваемых первичных ключей

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

атрибута. Больше не нужно переопределять первичные ключи во всех моделях.

Сохраняя историческое поведение, значение по умолчанию
— . Начиная с версии 3.2 новые проекты создаются со значением
. Кроме того, новые приложения создаются со

значением . В будущем выпуске Django значение по умолчанию будет изменено на
.

Чтобы избежать нежелательных миграции в будущем, либо в явном виде установить
на :

DEFAULT_AUTO_FIELD = 'django.db.models.AutoField'

или настройте его для каждого приложения:

from django.apps import AppConfig

class MyAppConfig(AppConfig):
    default_auto_field = 'django.db.models.AutoField'
    name = 'my_app'

или для каждой модели:

from django.db import models

class MyModel(models.Model):
    id = models.AutoField(primary_key=True)

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

Функциональные показатели

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

from django.db import models
from django.db.models import F, Index, Value
from django.db.models.functions import Lower, Upper


class MyModel(models.Model):
    first_name = models.CharField(max_length=255)
    last_name = models.CharField(max_length=255)
    height = models.IntegerField()
    weight = models.IntegerField()

    class Meta
        indexes = 
            Index(
                Lower('first_name'),
                Upper('last_name').desc(),
                name='first_last_name_idx',
            ),
            Index(
                F('height')  (F('weight') + Value(5)),
                name='calc_idx',
            ),
        

Функциональные индексы добавляются к моделям с помощью
опции.

поддержка

Новый бэкэнд кеширования позволяет использовать библиотеку pymemcache для memcached. Требуется 3.4.0 или выше. Подробнее см. Документацию по кешированию в Django .

Новые декораторы для админки

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

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

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

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

Общие примечания ¶

Постоянные соединения

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

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

Управление подключением

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

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

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

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

Предостережения

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

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

Сервер разработки создает новый поток для каждого обрабатываемого запроса, сводя на нет эффект постоянных подключений. Не включайте их во время разработки.

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

CRUD операции

Альтернативный способ создания нового экземпляра модели Django:

anupam = Student.objects.create(name = "Anupam", email = "anupam@journaldev.com",age = "24", website = "www.journaldev.com",section="A")

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

from school.models import Student
from django.http import HttpResponse

def randomFunctionFilter(request):
   res = ''
   
   object = Student.objects.filter(name = "Anupam")
   res += "Found : %s students<br>"%len(object)
   
   obj = Student.objects.order_by("age")
   
   for elt in obj:
      res += elt.name + '<br>'
   
   return HttpResponse(res)

Как отфильтровать больше и меньше?

object = Student.objects.filter(age__lt 10)
object = Student.objects.filter(age__gt 20)

Обновление данных:

student = Student.objects.get(name='Anupam')
student.age = 100
student.save()

student = Student.objects.get(name='Anupam')
student.delete()

from django.db import models

class Me(models.Model):
    size = models.IntegerField()

    class Meta:
        ordering = 
        verbose_name = "m"
        verbose_name_plural = "meee"
        db_table = "Mytable"

ordering = в порядке убывания.

Создадим свое первое представление¶

Давайте создадим свое первое представление. Откроем файл и добавим следующий код:

polls/views.py

from django.http import HttpResponse


def index(request):
    return HttpResponse("Hello, world. You're at the polls index.")

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

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

polls/
    __init__.py
    admin.py
    apps.py
    migrations/
        __init__.py
    models.py
    tests.py
    urls.py
    views.py

В файл добавим следующий код:

polls/urls.py

from django.conf.urls import url

from . import views

urlpatterns = 
    url(r'^$', views.index, name='index'),

Следующий шаг – добавить ссылку на в главной конфигурации URL-ов. В«mysite/urls.py« добавим импорт , затем добавим в список . Вы должны получить следующий код:

mysite/urls.py

from django.conf.urls import include, url
from django.contrib import admin

urlpatterns = 
    url(r'^polls/', include('polls.urls')),
    url(r'^admin/', admin.site.urls),

Не совпадает с тем, что у вас получилось?

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

Вы добавили в настройки URL-ов. Давайте проверим, что он работает, запустив команду:

$ python manage.py runserver

Откройте в браузере http://localhost:8000/polls/, вы должны увидеть текст “Hello, world. You’re at the polls index.”, который вы указали в представлении .

Функция принимает четыре аргумента, два обязательных: и , и два необязательных: и . Давайте изучим эти аргументы.

argument: regex

Термин “regex” обычно используется как короткий вариант “regular expression”(регулярное выражение), который являет шаблоном для распознавания строк, или в нашем случае URL-ов. Django начинает с первого регулярного выражение и идет дальше по списку, сравнивая запрошенный URL с каждым регулярным выражением пока не будет найдено совпадение.

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

При запросе на , так же будет проверяться .

Если вам нужна помощь с регулярными выражениями, почитайте статью в Википедии и документацию модуля . Также книга O’Reilly “Mastering Regular Expressions”, написанная Jeffrey Friedl, просто фантастична. На практике, однако, вам не нужно быть экспертом в регулярных выражениях, т.к. в основном вам нужно знать как составлять простые регулярные выражения. На практике сложные регулярные выражения могу влиять на производительность, по этому не следует полагаться на их широкие возможности.

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

argument: view

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

argument: kwargs

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

argument: name

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

Изучив основы о запросах и ответах, приступим ко второй части учебника, чтобы начать работать с базой данных.

Плюсы Джанго

Принцип «Всё включено» («Batteries included»)

Фраза «всё включено» означает, что большинство инструментов для создания приложения — часть фреймворка, а не поставляются в виде отдельных библиотек.

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

• ORM
• Миграции базы данных
• Аутентификация пользователя
• Панель администратора
• Формы

Стандартизированная структура

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

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

Приложения Django

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

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

Безопасный по умолчанию

Django безопасен из коробки и включает механизмы предотвращения распространенных атак вроде SQL-инъекций (XSS) и подделки межсайтовых запросов (CSRF). Подробнее об этом можно почитать в официальном руководстве по безопасности.

REST Framework для создания API

Django REST Framework, который часто сокращают до «DRF», является библиотекой для построения API. Он имеет модульную и настраиваемую архитектуру, которая хорошо работает для создания как простых, так и сложных API.

В DRF политики аутентификации и разрешений доступны из коробки. Он поставляется с базовыми классами для CRUD операций и встроенной утилитой для тестирования разрабатываемого API.

GraphQL фреймворк для создания API

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

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

Размещение Django сайта на Heroku

Последний шаг — это фактическое размещение кода на Heroku. Если вы раньше настраивали сервер, вы будете поражены тем, как сильно Heroku упрощает данный процесс.

Весь процесс будет состоять из следующих этапов:

• создайте новое приложение на Heroku и вставьте в него наш код;
• настройте взаимодействие с git, то есть так называемый «hook» для Heroku;
• настройте приложение на игнорирование статических файлов;
• для активации приложения в онлайн режим, запустите сервер Heroku;
• посетите приложение, перейдя по предоставленному Heroku URL адресу.

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

Shell

(pages) $ heroku create
Creating app… done, ⬢ fathomless-hamlet-26076
https://fathomless-hamlet-26076.herokuapp.com/ |
https://git.heroku.com/fathomless-hamlet-26076.git

1 2 3 4

(pages)$heroku create Creating app…done,⬢fathomless-hamlet-26076 httpsfathomless-hamlet-26076.herokuapp.com| httpsgit.heroku.comfathomless-hamlet-26076.git

На данный момент нам остается только настроить Heroku. Для этого укажем Heroku проигнорировать статические файлы вроде CSS и JavaScript, которые Django по умолчанию попытается исправить под себя. Выполним следующую команду:

Shell

(pages) $ heroku config:set DISABLE_COLLECTSTATIC=1

1	(pages)$heroku configset DISABLE_COLLECTSTATIC=1

Теперь можем разместить код на Heroku.

Shell

(pages) $ git push heroku master

1	(pages)$git push heroku master

Если бы мы только что набрали , то код был бы загружен в GitHub, а не в Heroku. Добавление слова в команду позволяет отправить код на Heroku. Первые несколько раз это может сбивать с толку.

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

Введите следующую команду.

Shell

(pages) $ heroku ps:scale web=1

1	(pages)$heroku psscale web=1

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

Shell

(pages) $ heroku open

1	(pages)$heroku open

Наш адрес . Вы можете убедиться в этом, вот появившаяся домашняя страница:

Домашняя страница на Heroku

Страница «About» также открылась должным образом:

Страница «About» на Heroku

Вам нет нужды разлогиниваться или покидать свое приложение в Heroku. Оно будет работать само по себе на этом бесплатном уровне.

Внешние ключи

Создадим новую модель Django и добавим внешний ключ.

class Teacher(models.Model):
    name = models.CharField(max_length=100)
    students = models.ManyToManyField(Student)
    user = models.ForeignKey('auth.User', on_delete=models.CASCADE)

    def __str__(self):
        return self.name

Метод str определяет удобочитаемое представление модели, которое отображается на сайте администратора Django и в оболочке Django.

Внешний ключ связан с другим классом. На этот раз встроенный класс django:

• CASCADE: при удалении объекта, на который имеется ссылка, также удалите объекты, которые имеют на него ссылки (например, при удалении сообщения в блоге вы также можете удалить комментарии).
• PROTECT: запретить удаление указанного объекта. Чтобы удалить его, вам придется вручную удалить все объекты, которые на него ссылаются.
• SET_NULL: установите для ссылки значение NULL (требуется, чтобы поле допускало значение NULL). Например, когда вы удаляете пользователя, вы можете захотеть сохранить комментарии, которые он разместил к сообщениям в блоге, но сказать, что они были опубликованы анонимным (или удаленным) пользователем.
• SET_DEFAULT: установить значение по умолчанию.

3.7. Создаем контакты

POST-перенаправление-GET

• из контекста — это Django Form для нашей модели. Так как мы не указали ни одного своего, Django создал один для нас. Как заботливо;
• если бы мы просто написали мы бы получили табличные ряды; но мы добавляем , что заставляет выводить поля ввода как элементы ненумерованного списка. Попробуйте вместо этого использовать и посмотреть что из этого получится;
• когда мы выводим форму (пр.: автоматически сгенерированную) выводятся только наши поля, но не обрамляющий форму тег
  шаблонный тег вставляет скрытое поле, по которому Django определяет, что запрос пришел с вашего проекта и что это не межсайтовая подделка запроса (CSRF). Попробуйте не включать его в шаблон: вы все еще будете иметь доступ к странице, но как только вы попробуете отправить форму — вы получите ошибку;
  мы используем шаблонный тег для генерирования ссылки назад к списку контактов. Замете, что — это имя нашего представления, которое мы указали в настройках URL. Используя вместо полного пути, нам не придется беспокоится про битые ссылки. в шаблоне является эквивалентом в коде Python.

PHP против Python

PHP можно назвать самым сильным конкурентом Python, оба эти языка очень популярны. Однако у Django есть парочка роялей в кустах, которыми не может похвастаться PHP. Нередко эти преимущества являются решающими для разработчиков. Выбор между PHP и Python – не самая простая задача, надеюсь следующие сравнения помогут вам сделать объективный вывод:

1. Лучший дизайн: PHP был разработан специально для веб разработки, но Django базируется на более надежном языке. Хороший код проще написать в Python, в сравнении с PHP.
2. Python и долгосрочность: PHP очень хорош в краткосрочной перспективе. Однако, когда вы проходите начальную фазу, вам может понадобиться язык с более глубокими возможностями. Здесь Python выступает в роли явного фаворита.
3. Лучший Веб Фреймворк: Рынок наполнен великим множеством замечательных фреймворков. Однако это не касается долгосрочной ценности. И Django в данном случае является явным победителем. Хотя и PHP может похвастаться со своими Laravel, Yii, Symfony.
4. Фактор читаемости: PHP следует классическому подходу, но у Python более строгие правила идентификации. Отсюда выбирайте, что лучше.
5. Простой синтаксис: написание кода в Python происходит намного проще и быстрее.
6. Инструменты для лечения багов: пакеты Python содержат все необходимые инструменты для исправления неполадок.
7. Управление пакетам: в Python это реализовано весьма эффективно: вы можете писать, читать и делиться пакетами таким образом, что другие разработчики могут использовать их в других приложениях.
8. Говорим Python, подразумеваем «Общее Назначение»: В то время как PHP используется для веб разработки, Python может быть использован для различных целей, также стоит отметить, что вы можете работать как онлайн, так и оффлайн.

License

Copyright 2011-present, Encode OSS Ltd.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this
  list of conditions and the following disclaimer.

• Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.

• Neither the name of the copyright holder nor the names of its
  contributors may be used to endorse or promote products derived from
  this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS «AS IS» AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Ресурсы по Django REST

• Обзор «Как разрабатывать API при помощи фреймворка Django REST» (How to Develop APIs with Django REST Framework) описывает все шаги по созданию API при помощи Django REST, начиная со среды разработки. В обзоре используется подход под названием «Разработка через тестирование» (test-driven development, TDD).
• Официальное руководство — это один из лучших источников информации для любого проекта с открытым исходным кодом. Также много полезной информации можно найти на официальном сайте фреймворка.
• Django: создание REST API — это первая часть великолепной серии статей про данный фреймворк (DRF). Вот остальные части:
  • Знакомимся с DRF (Django REST Framework: Getting Started).
  • Сериализаторы (Django REST Framework: Serializers).
  • Сериализаторы моделей и генераторы представлений (Django REST Framework: ModelSerializer and Generic Views).
  • ViewSet, ModelViewSet и маршрутизаторы (Django REST Framework: ViewSet, ModelViewSet and Router).
  • Аутентификация и разрешения (Django REST Framework: Authentication and Permissions).
  • JSON веб-токены (Django REST Framework: JSON Web Tokens (JWT)).
• Статья «Как оптимизировать ваши представления Django REST» (How to Optimize Your Django REST Viewsets) дает пошаговую инструкцию (с конкретными примерами), как избежать большого количества ненужных запросов, используя методы  и  в слоях Django ORM.
• Как сохранить дополнительные данные в сериализаторе Django REST ( How to Save Extra Data to a Django REST Framework Serializer)  — это краткое и удобное руководство для объединения дополнительных данных с уже определенными полями сериализатора DRF перед сохранением всего в базу данных или аналогичным действием.
• Интерфейс запросов в Django REST Framework (Django polls api using Django REST Framework) — это отличное руководство по созданию серверной части приложения для запросов (пошаговый разбор кода прилагается).
• Статья «Глубокий разбор классов permission в Django REST Framework» (Django REST Framework Permissions in Depth) содержит примеры кода и объясняет разницу между классами permission и authentication.
• Оптимизация производительности Django REST Framework (Optimizing slow Django REST Framework performance).
• Сериализация данных авторизованных пользователей в Django REST Framework (TLT: Serializing Authenticated User Data With Django REST Framework).
• Создание API и представлений на основе классов с помощью Django REST Framework (Building an API with Django REST Framework and Class-Based Views).
• Простой вложенный API с использованием Django REST Framework (Simple Nested API Using Django REST Framework)
• Создание API в Django и Django Rest Framework (Building APIs with Django and Django Rest Framework)