Django: путь запроса и первый проект

Оглавление курса · Скачать все состояния проекта.

Учебная задача: Объяснить путь HTTP-запроса и получить первое представление проекта «Редакционный стол».

Входное состояние: Пустой каталог исходных файлов, знание функций Python и HTML. Выходное состояние: Проект desk с настройками, WSGI и представлением home, ожидающим запрос на /. Эта глава продолжает «Редакционный стол» — небольшой сайт заметок. Нужны основы Python, HTML и устройство HTTP-запроса. Используем Python 3.12 и Django 5.2.18 LTS; номер ветки выбран для этой серии. Полный каталог lesson-01 в архиве содержит собственные настройки, шаблоны и историю миграций. При самостоятельном прохождении выберите один снимок и отдельную локальную базу; смешивание файлов разных глав меняет договор примера.

Исходники подготовлены редакционным чтением. Зависимости, миграции, сервер и команды работы с данными здесь не выполнялись. Все описанные ответы и изменения являются ожидаемыми, example_execution: not_run.

Редакционный сайт начинается с обычного запроса браузера. Пользователь набирает адрес, сервер получает метод и путь, а приложение решает, какой ответ вернуть. Django помогает связать эти действия, но не отменяет HTTP: адрес страницы, заголовки и тело ответа остаются отдельными частями обмена. В первом уроке создадим основу «Редакционного стола». Пока у него нет заметок в базе и сложной вёрстки. Его единственная задача — ответить на корневой путь понятной строкой и показать место, где этот ответ формируется.

Мы используем Python 3.12 и ветку Django 5.2 LTS. В архиве закреплён Django 5.2.18; это выбранная версия курса, а не утверждение, что все другие ветки устарели. Не смешивайте документы разных поколений фреймворка: одинаковое название класса ещё не гарантирует одинаковое поведение. Для первой главы достаточно понимать импорт модуля, вызов функции и возвращаемое значение. Знание SQL пока не требуется. Команды подготовки ниже являются инструкцией для вашей среды; при подготовке материала они не выполнялись.

Что находится в проекте

Каталог desk содержит настройки всего сайта. Это место для выбора базы, регистрации приложений и подключения главного списка адресов. Файл manage.py служит точкой входа для административных команд Django. Он задаёт модуль настроек перед обращением к системе управления. Сам по себе этот файл не является представлением страницы и не определяет её содержимое. wsgi.py предоставляет объект приложения для серверного окружения. В разработке обычно работают через встроенный сервер, а при выпуске процесс обслуживает отдельный WSGI-сервер.

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

Настройки из архива рассчитаны на локальную разработку. DEBUG по умолчанию включён, а допустимые хосты ограничены локальными адресами. В демонстрации есть явно учебный ключ, пригодный только для собственного изолированного запуска. Когда DEBUG выключен, отсутствие отдельного ключа останавливает приложение. Это не настройка публикации «на всякий случай», а способ обозначить границу между учебной средой и выпуском. Секретный ключ не нужно размещать в HTML или обсуждать в открытом журнале.

Представление и адрес

Представление получает request и возвращает HttpResponse. request будет содержать сведения о запросе: метод, путь, параметры и другие данные. Мы пока не читаем их, потому что ответ для всех посетителей одинаков. Отсутствие обращения к request не делает параметр лишним: Django передаёт его по контракту вызова. Строка в HttpResponse становится телом ответа, а успешный статус по умолчанию равен 200. Даже короткий текст уже является полноценным HTTP-ответом.

Список urlpatterns соединяет пустой путь с функцией home. Пустая строка обозначает корень сайта; это не «любой адрес». Если вы запросите другой путь, совпадения в данном списке не будет. Параметр name присваивает маршруту устойчивое имя для будущего построения ссылок. Имя не меняет адрес в браузере. Позднее мы будем обращаться к именам в шаблонах, чтобы изменение пути не требовало поиска строк по всему проекту.

Проследите цепочку на бумаге: запрос / приходит к приложению, настройки указывают ROOT_URLCONF, Django читает desk.urls, находит маршрут и вызывает home. Затем ответ возвращается через обслуживающий сервер браузеру. Ни база, ни шаблонизатор в этом конкретном пути не участвуют. Это полезно помнить при ошибке: искать проблему с таблицами бессмысленно, если выполнение ещё не дошло до обращения к модели.

Различаем ответ и среду

Ожидаемый результат — текст «Редакционный стол: первая заметка». Если вместо него браузер не соединяется с адресом, проблема лежит раньше представления: процесс не обслуживает запрос или выбран другой порт. Если соединение есть, но приходит 404, проверьте путь и подключённый URLconf. Если Django сообщает об ошибке импорта, сравните имя функции и модуля. Эти ситуации имеют разные причины; попытка исправить их одной заменой настроек обычно только добавляет неопределённость.

Попробуйте самостоятельно заменить тело ответа на две короткие строки. Браузер не обязан показывать перенос так же, как обычный текстовый редактор: по умолчанию HttpResponse использует HTML-тип содержимого. Для настоящего текстового ответа можно явно задать content_type="text/plain; charset=utf-8". Так вы увидите, что значение ответа и способ его интерпретации различаются. Следующая глава выделит предметную часть сайта в приложение notes, сохранив уже понятный путь запроса.

Разбор связи файлов

Проследите один запрос по двум разным путям. В обычном случае имя home найдено в таблице URL, функция получает объект запроса и возвращает ответ с текстом. При неизвестном пути функция вообще не вызывается: маршрутизатор не нашёл соответствия. Следовательно, добавление строки в тело home не исправит неверный URL. Сначала определите, дошёл ли запрос до представления, и только затем рассматривайте построение ответа.

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

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

Полные файлы этого шага

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

desk/views.py

from django.http import HttpResponse

def home(request):
    return HttpResponse("Редакционный стол: первая заметка")

desk/urls.py

from django.urls import path
from .views import home

urlpatterns = [path("", home, name="home")]

Документация и исходники

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