Содержание
Данная глава временно взята из первой версии книги и подлежит корректировке. Вы можете помочь с этим!
Перевод © Попов Руслан <radz • yandex • ru>
И снова повторимся: со своей худшей стороны веб разработка является нудным и монотонным процессом. Также мы рассказывали, что Django пытается избавить вас от этой монотонности на уровнях моделей и шаблонов, но остаётся ещё уровень представлений.
Базовые представления Django были разработаны для облегчения решения этой проблемы. Они следуют общим определённым идиомам и шаблонам, которые были найдены во время разработки представлений, и позволяют быстро создавать общие представления на основе минимума кода. Действительно, почти каждый пример представления в предыдущих главах может быть переписан с использованием базовых представлений.
Глава «Усовершенствованные представления и схемы URL» кратко касалась вопроса как можно сделать представление «базовым». При решении этой задачи мы можем выделить общие шаги, такие как отображение списка объектов, создание кода, который может выводить список любых объектов. Тогда рассматриваемую модель можно передать в виде дополнительного параметра в файл со схемой URL.
Django поставляется с базовыми представлениями:
Выполнение общих «простых» задач: перенаправление на другую страницу и обработка шаблона страницы.
Отображение списка и подробной страницы для одного объекта. Представления event_list и entry_list из главы «Усовершенствованные представления и схемы URL» являются примерами представлений, которые отображают списки. Страница для одного события является примером, который мы называем «детальным» представлением.
Отображение объектов для работы с датой на архивных страницах, ассоциированных подробностей и страниц с «свежей» информации. Архивы блогов о Django (http://www.djangoproject.com/weblog/) с доступом по годам, месяцам и дням созданы на этой основе.
Позволяет пользователям создавать, изменять и удалять объекты — с и без авторизации.
Объединённые вместе, эти представления предоставляют простой интерфейс для решения наиболее общих задач с которыми сталкиваются разработчики.
Все эти представления используются с помощью создания конфигурационных словарей в ваших файлах со схемой URL и передачи этих словарей в качестве третьего аргумента кортежа для определённого шаблона.
Ниже представлен простой файл со схемой URL, который можно использовать для представления статичной страницы «Информация о»:
from django.conf.urls.defaults import *
from django.views.generic.simple import direct_to_template
urlpatterns = patterns('',
('^about/$', direct_to_template, {
'template': 'about.html'
})
)
Несмотря на то, что на первый взгляд здесь есть нечто «магическое» — посмотрите, представление без кода! — это то же, что и примеры из главы «Усовершенствованные представления и схемы URL»: представление direct_to_template просто получает информацию из словаря дополнительных параметров и использует эту информацию при отображении представления.
Так как это базовое представление, как и все остальные, является обычным представлением, которое функционирует подобно другим, мы можем использовать его внутри наших собственных представлений. В качестве примера, давайте улучшим наш пример «Информация о» для вывода для URL вида /about/что-то/ статических страниц about/что-то.html. Мы сделаем это сначала изменив привязку:
from django.conf.urls.defaults import *
from django.views.generic.simple import direct_to_template
from mysite.books.views import about_pages
urlpatterns = patterns('',
('^about/$', direct_to_template, {
'template': 'about.html'
}),
('^about/(\w+)/$', about_pages),
)
Затем мы напишем представление about_pages:
from django.http import Http404
from django.template import TemplateDoesNotExist
from django.views.generic.simple import direct_to_template
def about_pages(request, page):
try:
return direct_to_template(request, template="about/%s.html" % page)
except TemplateDoesNotExist:
raise Http404()
Здесь мы рассматриваем direct_to_template как
любую другую функцию. Так как она возвращает
HttpResponse
, мы можем отдавать его без обработки. Есть только одна хитрость — работа при
отсутствии шаблонов. Нам не нужна ошибка, которая при этом
возникнет, следовательно мы ловим исключения
TemplateDoesNotExist и возвращаем вместо этого
ошибку 404.
Есть ли проблемы с безопасностью?
Внимательные читатели могли отметить возможную дыру в безопасности: мы создаём имя шаблона, используя информацию от браузера (template="about/%s.html" % page). На первый взгляд, это похоже на уязвимость выход из каталога (directory traversal) (обратитесь за подробностями к главе «Безопасность»). Но так ли это?
Не совсем. Специально подобранное значение параметра
page
может привести к выходу из каталога,
но несмотря на то, что page
получается из URL, не каждое значение
будет обработано. Вся хитрость в шаблоне URL: мы используем
регулярное выражение \w+ для совпадения с
page
частью URL, а \w
принимает только буквы и числа. Следовательно, любые
вредоносные символы (такие как точки и слэши) будут
отброшены в момент поиска функции представления для
обработки переданного URL.
2 комментария | Оставьте комментарий
Начиная с версии 1.5 Базовые представления (function-based generic view modules) устарели и заменены на Class-based views.
По-моему, даже в 1.3 уже появились CBV.