Хостинг Django от «Джино»
Table of contents

Глава 15. Компоненты

Данная глава временно взята из первой версии книги и подлежит корректировке. Вы можете помочь с этим!

Перевод © Попов Руслан <radz • yandex • ru>

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

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

Каждый компонент этой системы отвечает за выполнение определённой задачи. Если вы читаете эту книгу с самого начала, вы уже встречались с такими компонентами:

  • Все инструменты для работы с сессиями и пользователями, описанные в главе «Сессии, пользователи и регистрация», появились благодаря этой системе. Точнее, компоненты были подключены к вашей функции представления с помощью модулей request.session и request.user.

  • Кэш для сайта, описанный в главе «Кэширование», на самом деле является таким компонентом, который пропускает через себя вызов вашей функции представления в случае, когда это представление уже было помещено в кэш.

  • Сторонние приложения, такие как flatpages, redirects и csrf, описанные в главе «Средства от других разработчиков», делают всю свою волшебную работу через систему компонентов.

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

Что такое компоненты?

Компонент является обычным классом языка Python, который соответствует определённому API. Перед изучением формальных аспектов API, давайте рассмотрим очень простой пример.

Сайты с высокой нагрузкой часто нуждаются в установке Django за балансировщиком нагрузки (обратитесь к главе «Развёртывание Django»). Это может вызвать некоторые трудности, одной из которых является то, что каждый IP адрес от которого идёт запрос (request.META['REMOTE_IP']) будет теперь указывать на балансировщик, а не актуальный IP адрес. Балансировщики нагрузки решают эту проблему установкой специального заголовка, X-Forwarded-For, назначая ему IP адрес машины, которая сделала запрос.

Ниже приведён код небольшого компонента, который позволяет сайтам, работающим за балансировщиком, получать правильный IP адрес из request.META['REMOTE_IP']:

class SetRemoteAddrFromForwardedFor(object):
    def process_request(self, request):
        try:
            real_ip = request.META['HTTP_X_FORWARDED_FOR']
        except KeyError:
            pass
        else:
            # HTTP_X_FORWARDED_FOR может быть списком IP адресов,
            # разделённых запятой. Берём только первый.
            real_ip = real_ip.split(",")[0]
            request.META['REMOTE_ADDR'] = real_ip

Если этот компонент установлен (обратитесь к следующей секции), значение X-Forwarded-For каждого запроса будет автоматически помещено в request.META['REMOTE_ADDR']. Это означает, что вашему приложению больше не требуется определять работает ли оно за балансировщиком или нет. Оно может просто использовать request.META['REMOTE_ADDR'] и всё будет работать как надо.

Действительно, этот функционал нужен многим и должен быть встроен в Django. Так и есть, он находится в django.middleware.http, и вы можете узнать о нём больше в следующем разделе.


Ищем Python программистов

Found misprint?
Select it with the mouse and hit Enter
Ctrl-Enter
Processed:
33 1 199 25


The full repository of DjangoBook translation you can get on GitHub.
We appreciate your patches!

We are glad to hear your questions, comments or suggestions!
(Open in new tab)

Users number: 601

Русская группа

на поддержку перевода
Яндекс Яндекс.Деньги Хочу такую же кнопку
Ускорить процесс перевода!
ЯМ:41001223475816


© 2008-2012 Ruslan Popov @ gmail.com Powered by Django 1.2.5