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

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

Пакет django.contrib.humanize содержит ряд шаблонных фильтров, которые могут использоваться для придания данным «человеческого облика». Чтобы включить эти фильтры в свое приложение, добавьте строку ‘django.contrib.humanize’ в параметр INSTALLED_APPS. Затем просто включите в шаблон директиву {% load humanize %}. Ниже описаны входящие в пакет фильтры¹.

Пакет django.contrib.csrf защищает от подделки HTTP-запросов методом CSRF (cross-site request forgery), который иногда еще называют «угон сеанса». Это происходит, когда вредоносный сайт заставляет ничего не подозревающего пользователя загрузить URL с сайта, на котором пользователь уже аутентифицирован, и тем самым приобретает все права аутентифицированного пользователя. Чтобы понять, как это происходит, рассмотрим два примера.

Подсистема переадресации в Django позволяет управлять переадресацией, сохраняя необходимую информацию в базе данных в виде обычных объектов модели. Например, можно сказать фреймворку Django: «Переадресуй любой запрос к /music/ на /sections/arts/music/». Это удобно, когда требуется изменить структуру сайта: веб-разработчик обязан принимать все меры к тому, чтобы не было «битых» ссылок.

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

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

Сценарий 1: повторное использование данных в нескольких сайтах

находится в пакете django.contrib. В каждом его подпакете представлена какая-то отдельная часть функциональности. Эти части необязательно взаимосвязаны, но некоторые подпакеты зависят от других.

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

Иногда кэширование страницы целиком не дает существенного выигрыша и даже оказывается чрезмерным и неудобным.

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

Если необходим еще более точный контроль над кэшированием, можно воспользоваться тегом cache и с его помощью организовать кэширование фрагментов шаблона. Чтобы открыть шаблону доступ к этому тегу, поместите в начале шаблона директиву {% load cache %}.

Шаблонный тег {% cache %} кэширует содержимое блока на указанное время. Он принимает по меньшей мере два аргумента: время хранения в кэше в секундах и имя фрагмента. Например:

Сейчас в конфигурации URL определен только один шаблон URL - для обработки запросов к URL /hello/. Но что произойдет, если в запросе будет указан какой-нибудь другой URL?

Для того чтобы разобраться в этом, запустите сервер разработки Django и попробуйте зайти, скажем, на страницу http://127.0.0.1:8000/goodbye/, http://127.0.0.1:8000,/hello./subdirectory/ или даже http://127.0.0.1:8000/ (в «корень» сайта). Вы увидите сообщение «Page not found» (Страница не найдена) (см. рис. 3,1). Django выводит это сообщение при обращении к адресам URL, отсутствующим в конфигурации.