Представления и маршрутизация
Центральным моментом любого веб-приложения является обработка запроса, который отправляет пользователь. В Django за обработку запроса отвечают представления или views . По сути представления представляют функции обработки, которые принимают данные запроса в виде объекта HttpRequest из пакета django.http и генерируют некоторый результат, который затем отправляется пользователю.
По умолчанию представления размещаются в приложении в файле views.py .
Например, возьмем стандартный проект, в который добавлено приложение (например, проект созданный в прошлой главе).
При создании нового проекта файл views.py имеет следующее содержимое:
from django.shortcuts import render # Create your views here.
Данный код пока никак не обрабатывает запросы, он только импортирует функцию render() , которая может использоваться для обработки.
Генерировать результат можно различными способами. Один из них представляет использование класса HttpResponse из пакета django.http, который позволяет отправить текстовое содержимое.
Так, изменим файл views.py следующим образом:
from django.http import HttpResponse def index(request): return HttpResponse("Главная") def about(request): return HttpResponse("О сайте") def contact(request): return HttpResponse("Контакты")
В данном случае определены три функции, которые будут обрабатывать запросы. Каждая функция принимает в качестве параметра request объект HttpRequest , который хранит информацию о запросе. Однако в данном случае она нам не нужны, поэтому параметр никак не используется. Для генерации ответа в конструктор объекта HttpResponse передается некоторая строка. Это может быть в том числе и код html в виде строки.
Чтобы эти функции сопоставлялись с запросами, надо определить для них маршруты в проекте в файле urls.py . В частности, изменим этот файл следующим образом:
from django.urls import path from hello import views urlpatterns = [ path('', views.index), path('about', views.about), path('contact', views.contact), ]
Переменная urlpatterns определяет набор сопоставлений функций обработки с определенными строками запроса. Например, запрос к корню веб-сайта будет обрабатываться функцией index, запрос по адресу «about» будет обрабатываться функцией about, а запрос «contact» — функцией contact.
Запустим проект и обратимся по некоторым из этих адресов.
При этом мы можем отправлять не простой текст, а, например, код html, который затем интерпретируется браузеромю. Так, изменим файл views.py следующим образом:
from django.http import HttpResponse def index(request): return HttpResponse("Главная
") def about(request): return HttpResponse("О сайте
") def contact(request): return HttpResponse("Контакты
")
Соответственно теперь браузер получит код html:
Request django что это
Функции-представления в качестве обязательного параметра получают объект HttpRequest , который хранит информацию о запросе. HttpRequest определяет ряд атрибутов, которые хранят информацию о запросе. Выделим следующие из них:
- scheme : схема запроса (http или https)
- body : представляет тело запроса в виде строки байтов
- path : представляет путь запроса
- method : метод запроса (GET, POST, PUT и т.д.)
- encoding : кодировка
- content_type : тип содержимого запроса (значение заголовка CONTENT_TYPE)
- GET : объект в виде словаря, который содержит параметры запроса GET
- POST : объект в виде словаря, который содержит параметры запроса POST
- COOKIES : отправленные клиентом куки
- FILES : отправленные клиентом файлы
- META : хранит все доступные заголовки http в виде словаря. Набор заголовков зависит от клиента и сервера, некоторые из них:
- CONTENT_LENGTH : длина содержимого.
- CONTENT_TYPE : MIME-тип запроса.
- HTTP_ACCEPT : типы ответа, которые принимает клиент.
- HTTP_ACCEPT_ENCODING : кодировка, в которой клиент принимает ответ.
- HTTP_ACCEPT_LANGUAGE : язык ответа, который принимает клиент.
- HTTP_HOST : хост сервера.
- HTTP_REFERER : страница, с которой клиент отправил запрос (при ее наличии).
- HTTP_USER_AGENT : юзер-агент или информация о браузере клиента.
- QUERY_STRING : строка запроса.
- REMOTE_ADDR : IP-адрес клиента.
- REMOTE_HOST : имя хоста клиента.
- REMOTE_USER : аутентификационные данные клиента (при наличии)
- REQUEST_METHOD : тип запроса (GET, POST).
- SERVER_NAME : имя хоста сервера.
- SERVER_PORT : порт сервера.
Также HttpRequest определяет ряд методов. Отметим следующие из них:
- get_full_path() : возвращает полный путь запроса, включая строку запроса
- get_host() : возвращает хост клиента, для этого используется значения заголовков HTTP_X_FORWARDED_HOST (если включена опция USE_X_FORWARDED_HOST) и HTTP_HOST
- get_port() : возвращает номер порта
Например, получим некоторую информацию о запросе. Для этого в файле views.py :
from django.http import HttpResponse def index(request): host = request.META["HTTP_HOST"] # получаем адрес сервера user_agent = request.META["HTTP_USER_AGENT"] # получаем данные бразера path = request.path # получаем запрошенный путь return HttpResponse(f"""
Host:
Path:
User-agent: """)
В данном случае получаем два заголовка «HTTP_HOST» и «HTTP_USER_AGENT» и запрошенный путь.
В файле urls.py зарегистрируем данную функцию:
from django.urls import path from hello import views urlpatterns = [ path("index", views.index), ]Представления в Django – время создавать!
view, или представление, — это то место, где мы разместим «логику» работы нашего приложения. Оно запросит информацию из модели , которую мы создали ранее, и передаст её в шаблон . Шаблонами мы займёмся в следующей главе. Представления похожи на методы в Python и лишь немногим сложнее того, с чем мы уже сталкивались в главе Введение в Python.
Представления размещаются в файле views.py . Мы добавим свои представления в файл blog/views.py .
blog/views.py
Хорошо, давай откроем этот файл и посмотрим на его содержимое:
from django.shortcuts import render # Create your views here.Не слишком много кода.
Помнишь, что строки, начинающиеся с символа # — это комментарии? То есть Python не будет пытаться запустить их содержимое.
Простейшее представление может выглядеть следующим образом.
def post_list(request): return render(request, 'blog/post_list.html', <>)Как ты можешь заметить, мы создали функцию ( def ) с именем post_list , которая принимает request в качестве аргумента и возвращает ( return ) результат работы функции render , которая уже соберёт наш шаблон страницы blog/post_list.html .
Сохрани файл, перейди по адресу http://127.0.0.1:8000/ и посмотри, что у нас получилось.
Другая ошибка! Читаем, что произошло:
Это значит, что, по крайней мере, сервер снова работает, но что-то всё же пошло не так, верно? Не беспокойся, это просто страница с сообщением об ошибке, бояться совершенно нечего! Как и сообщения об ошибках в консоли, такие страницы чрезвычайно полезны. Здесь ты можешь прочесть: TemplateDoesNotExist — такого шаблона не существует. Давай исправим ошибку и создадим шаблон в следующей главе!
results matching » «
No results matching » «
Путь от request до response в Джанго
Веб-приложение или веб-сайт вращаются вокруг цикла запрос-ответ, и приложения Django не являются исключением. Но это не просто двухэтапный процесс. Наши приложения Django должны пройти различные стадии, чтобы вернуть конечному пользователю результат. Чтобы лучше понять структуру Django, мы должны понимать, как инициируются запросы и как конечный результат передается конечному пользователю. В следующих разделах я собираюсь объяснить различные этапы запросов и используемое там программное обеспечение или код.
При настройке нового проекта Django первое, что вы сделаете, это подключите ваши URLconfs и создадите какие-то представления. Но что на самом деле происходит «под капотом»? Как Django направляет трафик к представлению и какую роль играют промежуточное ПО (middleware) в этом цикле?
WSGI
Как мы знаем, веб-сервер — это программа, которая использует HTTP (протокол передачи гипертекста) для предоставления пользователям данных, формирующих веб-страницы, в ответ на их запросы, которые пересылаются HTTP-клиентами их компьютеров.
WSGI — это инструмент, созданный для решения основной проблемы: подключения веб-сервера к веб-среде. WSGI имеет две стороны: «серверная» и «прикладная». Для обработки ответа WSGI сервер выполняет приложение и предоставляет функцию обратного вызова на стороне приложения. Приложение обрабатывает запрос и возвращает ответ на сервер, используя предоставленный обратный вызов. По сути, обработчик WSGI действует как привратник между вашим веб-сервером (Apache, NGINX и т.д.) и вашим проектом на Django.
Между сервером и приложением лежат промежуточные программы (middleware). Вы можете думать о промежуточном программном обеспечении как о серии двунаправленных фильтров: они могут изменять (или замыкать) данные, передаваемые назад и вперед между сетью и вашим приложением Django.
Большая картина — поток данных
Когда пользователь делает запрос к вашему приложению, создается экземпляр обработчика WSGI, который:
- Импортирует ваш файл settings.py и классы исключений Django.
- Загружает все промежуточные классы, которые он находит в кортеже MIDDLEWARE_CLASSES или MIDDLEWARES (в зависимости от версии Django), расположенном в settings.py
- Создает четыре списка методов, которые обрабатывают запрос, представление, ответ и исключения.
- Перебирает методы запроса, выполняя их по порядку
- Определяет запрошенный URL
- Проходит через каждый из методов обработки представления
- Вызывает функцию отображения (обычно рендеринг шаблона)
- Обрабатывает любые методы исключения
- Проходит через каждый из методов ответа (изнутри, в обратном порядке из промежуточного ПО запроса)
- Наконец, создает возвращаемое значение и вызывает функцию обратного вызова на веб-сервере
Слои приложения Джанго
- Request Middlewares — Запрос промежуточного программного обеспечения
- URL Router (URL Dispatcher) — Маршрутизация URL
- Views — Отображения
- Context Processors — Контекстные процессоры
- Template Renderers — Рендер шаблонов
- Response Middlewares — Промежуточное программное обеспечение ответа
Всякий раз, когда поступает запрос, он обрабатывается промежуточным программным обеспечением. Мы можем иметь несколько промежуточных программ. Найти их можно в настройках проекта ( settings.py ). Промежуточное ПО запросов Django происходит по порядку при обработке запроса. Предположим, что если у нас есть запрос промежуточного программного обеспечения в порядке A, B, C, то запрос сначала обрабатывается промежуточным программным обеспечением A, а затем B, а затем C. Django предлагает связку промежуточного программного обеспечения по умолчанию. Мы также можем написать наши собственные или пользовательские промежуточные программы. После обработки запроса промежуточным программным обеспечением он будет отправлен на маршрутизатор URL (диспетчер URL).
URL-маршрутизатор примет запрос от промежуточного программного обеспечения запроса (request middleware) и получит путь URL-адреса из запроса. На основе пути URL-маршрутизатор попытается сопоставить путь запроса с доступными шаблонами URL-адреса. Эти шаблоны URL имеют форму регулярных выражений. После сопоставления пути URL с доступными шаблонами URL запрос будет отправлен в представление, связанное с URL.
Теперь мы находимся в слое бизнес-логики. Представления обрабатывают бизнес-логику, используя запрос и данные запроса (данные, отправленные в GET, POST и т.д.). После обработки в представлении запрос отправляется контекстным процессорам, с помощью обработчиков контекста запроса добавляет контекстные данные, которые помогут средству визуализации шаблонов визуализировать шаблон для генерации HTTP-ответа.
И снова запрос будет отправлен обратно в промежуточное программное обеспечение, но уже ответа ( response ) для его обработки. Промежуточное программное обеспечение ответа обработает запрос и добавит или изменит информацию заголовка /информацию тела перед отправкой обратно клиенту (браузеру). После этого браузер обработает и отобразит его для конечного пользователя.
Промежуточное программное обеспечение — Middleware
Промежуточное программное обеспечение используется в ряде ключевых функций в проекте Django: например мы используем промежуточное ПО CSRF для предотвращения атак подделки межсайтовых запросов. Они используются для обработки данных сеанса. Аутентификация и авторизация осуществляется с использованием промежуточного программного обеспечения. Мы можем написать наши собственные классы промежуточного программного обеспечения для формирования (или замыкания) потока данных через ваше приложение.
process_request
Промежуточное ПО Django должно иметь хотя бы один из следующих методов: process_request , process_response , process_view и process_exception . Это методы, которые будут собраны обработчиком WSGI и затем вызваны в порядке их перечисления. Давайте кратко рассмотрим django.contrib.auth.middleware.AuthenticationMiddleware , одну из промежуточных программ, которые устанавливаются по умолчанию при запуске django-admin.py startproject :
def get_user(request): if not hasattr(request, '_cached_user'): request._cached_user = auth.get_user(request) return request._cached_user class AuthenticationMiddleware(MiddlewareMixin): def process_request(self, request): assert hasattr(request, 'session'), ( "The Django authentication middleware requires session middleware" "to be installed. Edit your MIDDLEWARE%s setting to insert " "'django.contrib.sessions.middleware.SessionMiddleware' before " "'django.contrib.auth.middleware.AuthenticationMiddleware'." ) % ("_CLASSES" if settings.MIDDLEWARE is None else "") request.user = SimpleLazyObject(lambda: get_user(request))Как вы можете видеть, это промежуточное программное обеспечение работает только на этапе «запроса» потока данных, поступающего в приложение Django и из него. Это промежуточное программное обеспечение сначала проверяет, используется ли промежуточное программное обеспечение сеанса и уже было ли оно вызвано, затем устанавливает пользователя, вызывающего вспомогательную функцию get_user . Поскольку обработчик WSGI выполняет итерацию по списку методов process_request , он создает этот объект request , который в конечном итоге будет передан в представление, и вы сможете ссылаться на request.user . Некоторые из промежуточных программ в settings.py не будут иметь методы process_request . Ничего страшного; те просто пропускаются на этом этапе.
process_requests должен либо вернуть None (как в этом примере), либо альтернативно может вернуть объект HttpResponse . В первом случае обработчик WSGI продолжит обрабатывать методы process_request , а второй «закоротит» процесс и начнет цикл process_response .
Определение URL
Теперь, когда каждый из методов process_request был вызван, у нас теперь есть объект запроса, который будет передан представлению. Прежде чем это произойдет, Django должен разрешить URL и определить, какую функцию просмотра вызывать. Это просто делается путем сопоставления регулярных выражений. Ваш файл settings.py будет иметь ключ ROOT_URLCONF , который указывает на корневой файл urls.py , из которого вы будете включать файлы urls.py для каждого из ваших приложений. URL-маршрутизация довольно подробно описана в руководствах по Django, поэтому здесь нет необходимости углубляться в это.
Представление имеет три требования:
- Это должно быть вызваемым. Это может быть представление на основе функции или представление на основе класса, которое наследуется от метода as_view() класса View , чтобы сделать его вызываемым в зависимости от типа запроса HTTP (GET, POST и т.д.)
- Оно должно принимать объект HttpRequest в качестве первого позиционного аргумента. Это результат вызова всех методов process_request и process_view .
- Оно должно возвращать объект HttpResponse или вызывать исключение. Именно этот объект ответа используется для запуска цикла process_view обработчика WSGI.
process_view
Теперь, когда обработчик WSGI знает, какую функцию представления вызывать, он снова просматривает свой список методов промежуточного программного обеспечения. Метод process_view для любого промежуточного программного обеспечения Django объявлен так:
process_view(request, view_function, view_args, view_kwargs)Как и в случае с process_request , функция process_view должна возвращать либо None, либо объект HttpResponse (или вызывать исключение), что позволяет обработчику WSGI либо продолжать обработку представлений, либо «закорачивать» и возвращать ответ. Взгляните на исходный код промежуточного программного обеспечения CSRF, чтобы увидеть пример process_view в действии. Если файл cookie CSRF присутствует, метод process_view возвращает None, и выполняется представление. Если нет, запрос отклоняется, и процесс замыкается, что приводит к сообщению об ошибке.
process_exception
Если функция представления вызывает исключение, обработчик перебирает свой список методов process_exception . Эти методы выполняются в обратном порядке, от последнего промежуточного программного обеспечения, указанного в файле settings.py , до первого. Если возникает исключение, процесс будет закорочен, и никакие другие process_exception не будут вызваны. Обычно мы полагаемся на обработчики исключений, предоставляемые Django BaseHandler, но вы, безусловно, можете реализовать свою собственную обработку исключений, когда пишете свой собственный класс промежуточного ПО.
process_response
На этом этапе у нас будет объект HttpResponse , возвращаемый представлением или списком методов process_view , созданных обработчиком WSGI, и пришло время поочередно циклически проходить через промежуточное ПО ответа. Это последний шанс для любого промежуточного программного обеспечения изменить данные, и они выполняются из внутреннего слоя наружу. Взгляните на исходный код промежуточного программного обеспечения кеша, чтобы увидеть пример действия process_response : в зависимости от различных условий в вашем приложении (например, отключено ли кэширование, имеем ли мы дело с потоком и т.д.), Нам понадобится ответ хранится в кеше или нет.
Примечание: Есть одно отличие между Django до 1.10 и более поздними версиями: в старом MIDDLEWARE_CLASSES у каждого промежуточного программного обеспечения всегда будет вызываться метод process_response , даже если более раннее промежуточное программное обеспечение закорачивало процесс. В новом MIDDLEWARES только те промежуточные программы и те, которые выполнялись до этого, будут вызывать свои методы process_response . Обратитесь к документации для получения более подробной информации о различиях между MIDDLEWARES и MIDDLEWARE_CLASSES .
Все сделано!
Наконец, обработчик Django WSGI создает возвращаемое значение из объекта HttpResponse и выполняет функцию обратного вызова для отправки этих данных на веб-сервер и для пользователя.
Итак, два ключевых вывода:
- Теперь мы знаем, как функция представления сопоставляется с URLconf и что на самом деле вызывается (обработчик WSGI).
- Существует четыре ключевых момента, которые вы можете подключить к циклу запрос/ответ через свое собственное промежуточное ПО: process_request , process_response , process_view и process_exception .