Иногда возникает необходимость реализовать дополнительную обработку всех без исключения запросов, обслуживаемых Django. Такая обработка может понадобиться, чтобы модифицировать запрос перед передачей его в функцию представления, записать в журнал какие- нибудь сведения о запросе для отладки и т. д.
Механизм сеансов обеспечивает возможность сохранения данных между отдельными запросами. Но надо еще научиться использовать сеансы для аутентификации пользователей. Разумеется, мы не можем слепо верить тому, что пользователь говорит о себе, поэтому необходимо как-то проверить подлинность этой информации.
С учетом всех ограничений и потенциальных уязвимостей становится понятно, что cookies и сохраняемые сеансы являются примерами болевых точек веб-разработки. Но так как фреймворк Django стремится быть эффективным целителем, в него входит подсистема сеансов, предназначенная для преодоления этих трудностей.
Пора признаться: до сего момента мы осознанно игнорировали один важный аспект веб-разработки. До сих пор мы представляли посетителей сайта как безликую анонимную массу, налетающую на наши любовно спроектированные страницы.
Но на самом деле это, конечно, неверно. За каждым броузером, обращающимся к нашему сайту, стоит конкретный человек (ну, по большей части). И нельзя забывать, что Интернет по-настоящему имеет смысл, когда используется для соединения людей, а не машин. Разрабатывая неотразимый сайт, мы все же ориентируемся на тех, кто смотрит на экран броузера.
Для отображения шаблона необходим контекст. Обычно таковым является экземпляр класса django.template.Context, но в Django имеется также специальный подкласс django.template.RequestContext, который действует несколько иначе. RequestContext автоматически помещает в контекст несколько дополнительных переменных, например, объект HttpRequest или информацию о текущем аутентифицированном пользователе.
Последний прием, который мы рассмотрим, опирается на относительно редко используемую возможность Python. Предположим, что в разных представлениях многократно встречается один и тот же код, например:
def my_view1(request):
if not request.user.is_authenticated():
Раз уж мы заговорили о ветвлении по методу запроса, покажем, как это можно элегантно осуществить. Рассмотрим следующую строку в конфигурации URL:
# urls.ру
from django.conf.urls.defaults import *
from mysite import views
urlpatterns = patternsC’, tt . ..
Хотя мы уже несколько раз прошлись по форме для поиска книг и внесли ряд улучшений, по существу она осталась совсем простой: одно единственное поле ‘q’. Из-за этого нам даже не представилось случая воспользоваться имеющейся в Django библиотекой для работы с форма ми. Но для более сложных форм и обработка должна быть более слож ной, поэтому сейчас мы разработаем форму отзыва, которая позволяет пользователю сайта оставить свое замечание и необязательный адрес электронной почты. Проверив полученные данные, мы автоматически отправим по электронной почте сообщение персоналу сайта.
Как обычно, мы начали с простейшего работающего примера. А теперь рассмотрим некоторые проблемы и покажем, как их можно решить.
Во-первых, обработка пустого запроса в представлении searchQ явно недостаточна – мы просто выводим сообщение «Введите поисковый запрос», заставляя пользователя нажать кнопку «Назад» в броузере. Это крайне непрофессионально, и, если вы сделаете нечто подобное в действующем приложении, вас отлучат от Django.
Все на том же примере базы данных, содержащей информацию о книгах, авторах и издательствах, мы создадим простое представление, которое позволит отыскать книгу по названию.
В общем случае, с точки зрения разработки, у формы есть две стороны: пользовательский HTML-интерфейс и код для обработки отправленных данных на стороне сервера. С первой частью все просто, вот представление для отображения формы поиска:
