Django_-_podrobnoe_rukovodstvo

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

По умолчанию система­ кэширования в Django формирует ключи, используя путь, указанный в запросе пути (например, “/stories/2005/ jun/23/bank_robbed/”). Это означает, что в ответ на любой запрос к этому URL будет возвращена одна и та же кэшированная версия страницы вне зависимости от таких различий между броузерами пользователей, как cookie или языковые настройки. Но если содержимое страницы зависит от некоторых заголовков в запросе (cookie, язык, тип броузера), то об этом нужно сообщить механизмам кэширования с помощью заголовка Vary.

Для этого в Django применяется декоратор представления vary_on_ headers:

from django.views.decorators.vary import vary_on_headers

# Синтаксис Python 2.3. def my_view(request):

# ...

my_view = vary_on_headers(my_view, ‘User-Agent’)

# Синтаксис декоратора Python 2.4+. @vary_on_headers(‘User-Agent’)

def my_view(request):

#...

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

Преимущество декоратора vary_on_headers по сравнению с манипулированием заголовком Vary вручную (например, response[‘Vary’] = ‘useragent’) состоит в том, что декоратор добавляет информацию к заголовку Vary (а он может уже существовать), а не перезаписывает имеющиеся в нем данные.

Декоратору vary_on_headers() можно передать несколько заголовков:

@vary_on_headers(‘User-Agent’, ‘Cookie’) def my_view(request):

# ...

Тем самым промежуточные кэши уведомляются о том, что для каждой комбинации типа броузера и значения cookie в кэше должна быть создана отдельная версия страницы. Например, запрос, отправленный с помощью броузера Mozilla и со значением foo=bar в cookie будет считаться отличным от запроса, отправленного с помощью броузера Mozilla и со значением foo=ham в cookie.

Поскольку варьирование по cookie встречается очень часто, существует специальный декоратор vary_on_cookie. Следующие два представления эквивалентны:

@vary_on_cookie

def my_view(request):

# ...

@vary_on_headers(‘Cookie’) def my_view(request):

# ...

Регистр символов в названиях заголовков, передаваемых декоратору vary_on_headers, не имеет значения: “User-Agent” и “user-agent” эквивалентны.

Можно также напрямую использовать вспомогательную функцию django.utils.cache.patch_vary_headers. Она устанавливает или добавляет заголовок Vary , например:

from django.utils.cache import patch_vary_headers

def my_view(request):

# ...

response = render_to_response(‘template_name’, context) patch_vary_headers(response, [‘Cookie’])

return response

Функция patch_vary_headers принимает в качестве первого аргумента объект HttpResponse, а в качестве второго – список или кортеж названий заголовков, имена которых нечувствительны к регистру символов.

Управление кэшем: другие заголовки

Среди других проблем следует упомянуть конфиденциальность данных и вопрос о том, в каком месте каскада кэшей следует хранить данные.

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

Решение состоит в том, чтобы пометить страницу как «частную». В Django для этого применяется декоратор представления cache_control, например:

from django.views.decorators.cache import cache_control

@cache_control(private=True) def my_view(request):

#...

Взадачу этого декоратора входит отправка нужного HTTP-заголовка. Существует несколько способов управления параметрами кэширования. Например, спецификация HTTP позволяет:

•• Определить максимальное время нахождения страницы в кэше.

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

Декоратор cache_control в Django позволяет задать эти параметры. В примере ниже cache_control сообщает кэшу, что наличие изменений следует проверять при каждом обращении и хранить кэшированную версию не более 3600 секунд:

from django.views.decorators.cache import cache_control

@cache_control(must_revalidate=True, max_age=3600) def my_view(request):

#...

Вкачестве параметра декоратору cache_control() можно передать любую допустимую протоколом HTTP директиву заголовка Cache-Control. Вот их полный перечень:

•• public=True

•• private=True

•• no_cache=True

•• no_transform=True

•• must_revalidate=True

•• proxy_revalidate=True

•• max_age=num_seconds

•• s_maxage=num_seconds

(Отметим, что дополнительные процессоры всегда добавляют директиву max-age со значением, взятым из параметра настройки CACHE_ MIDDLEWARE_SETTINGS. Если декоратору cache_control передать другое значение max-age, то оно будет иметь приоритет.)

Чтобы полностью отменить кэширование, воспользуйтесь декоратором представления never_cache, который добавляет HTTP-заголовки, необходимые, чтобы ответ не кэшировался ни броузером, ни другими кэшами. Например:

from django.views.decorators.cache import never_cache

@never_cache

def myview(request):

# ...

Другие оптимизации

В Django есть и другие дополнительные процессоры, призванные оптимизировать производительность приложения:

•• django.middleware.http.ConditionalGetMiddleware реализует поддержку условных ответов на GET-запросы с помощью заголовков ETag и LastModified, реализованную в современных броузерах.

•• django.middleware.gzip.GZipMiddleware сжимает ответы (этот режим поддерживается всеми современными броузерами) для экономии пропускной способности сети и сокращения времени передачи.

Порядок строк в MIDDLEWARE_CLASSES

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

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

•• SessionMiddleware добавляет заголовок Cookie

•• GZipMiddleware добавляет заголовок Accept-Encoding

•• LocaleMiddleware добавляет заголовок Accept-Language

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

Что дальше?

В комплект поставки Django входит ряд пакетов, написанных сторонними разработчиками («contrib»), которые содержат ряд полезных возможностей. Некоторые из них мы уже рассматривали: административный интерфейс (см. главу 6) и подсистему­ управления сеансами и пользователями (см. главу 14). В следующей главе мы рассмотрим другие подсистемы­ такого рода.

16

django.contrib

Одной из сильных сторон языка Python является его идеология «батарейки входят в комплект»: в состав дистрибутива Python входит большая стандартная библиотека пакетов, которыми можно начинать пользоваться сразу же, не загружая что-то еще. Фреймворк Django также придерживается этой идеологии и поставляется с собственной стандартной библиотекой дополнительных модулей, полезных для решения типичных задач веб-разработки. Их-то мы в этой главе и рассмотрим.

Стандартная библиотека Django

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

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

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

Пакет django.contrib включает следующие подпакеты:

•• admin: административный интерфейс Django. См. главу 6.

•• admindocs: автоматически сгенерированная документация по административному интерфейсу. В этой книге не рассматривается, см. официальную документацию по Django.

•• auth: подсистема­ аутентификации Django. См. главу 14.

•• comments: приложение для управления комментариями. В этой книге не рассматривается, см. официальную документацию по Django.

•• contenttypes: подсистема­ подключения к типам содержимого, в которой каждая установленная модель Django является отдельным типом. Используется другими приложениями из пакета contrib и предназначена главным образом для очень опытных разработчиков. А они почерпнут гораздо больше, изучив исходный код, который находится в каталоге django/contrib/contenttypes.

•• csrf: защита от техники подделки HTTP-запросов CSRF (cross-site request forgery). См. ниже раздел «Защита от CSRF».

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

•• flatpages: подсистема­ для хранения простых «плоских» HTML-стра­ ниц в базе данных.

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

•• gis: расширение Django для поддержки геоинформационных сис­ тем (ГИС). С его помощью в моделях можно хранить географические данные и выполнять географические запросы. Это большая и сложная библиотека, которая в настоящей книге не рассматривается. Документация приводится на сайте http://geodjango.org/.

•• humanize: набор шаблонных­ фильтров, полезных для придания данным «человеческого облика». См. раздел «Удобочитаемость данных».

•• localflavor: разнообразный код, настроенный для разных стран и культур. Например, сюда включены средства для проверки почтовых индексов США (ZIP-кодов) и персональных идентификационных номеров в Исландии.

•• markup: набор шаблонных­ фильтров для реализации распространенных языков разметки. См. раздел «Фильтры разметки».

•• redirects: подсистема­ управления переадресацией. См. раздел «Переадресация».

•• sessions: подсистема­ сеансов. См. главу 14.

•• sitemaps: подсистема­ создания карт сайтов в формате XML. См. главу 13.

•• sites: подсистема,­ позволяющая эксплуатировать несколько вебсайтов при наличии всего одной базы данных и инсталляции Django. См. раздел «Сайты».

•• syndication: подсистема­ создания каналов синдицирования в форматах RSS и Atom. См. главу 13.

•• webdesign: дополнительные модули, предназначенные прежде всего для веб-дизайнеров (а не разработчиков). На момент написания этой книги включали единственный шаблонный­ тег {% lorem %}. Дополнительные сведения см. в документации по Django.

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

Сайты

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

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

В главе 1 мы рассказали о том, что созданные на основе Django сайты LJWorld.com и Lawrence.com эксплуатируются одной и той же организацией: газетой Lawrence Journal-World в городе Лоуренс, штат Канзас. Сайт LJWorld.com специализируется на новостях, а сайт Lawrence. com – на местных развлечениях. Но иногда возникает необходимость опубликовать некую статью на обоих сайтах.

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

Есть ли решение получше? Да, пусть оба сайта пользуются одной и той же базой статей, и каждая статья связана с одним или несколькими сайтами отношением многие-ко-многим. Подсистема­ сайтов в Django предоставляет таблицу базы данных, с которой можно связать статьи. Это общая точка, позволяющая ассоциировать данные с одной или несколькими «площадками».

Сценарий 2: хранение имени и домена сайта в одном месте

На сайтах LJWorld.com и Lawrence.com реализована система­ оповещения по электронной почте, с помощью которой читатели могут получать уведомления о новостях. Устроена она довольно просто: читатель заполняет веб-форму и сразу же получает по почте сообщение «Благодарим за оформление подписки».

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