Linuxformat - Вклад участника [ru]

LXF105:Django

2009-08-31T14:52:35Z

Shultais: Добавлена ссылка на сайт автора

: '''Новая серия!''' Разрабатываем динамические web-приложения современным способом[[Категория:Учебники]]

==''Django'': Новостной портал==

{{Цикл/Django}}

: '''ЧАСТЬ 1''' Нужен ли миру еще один новостной портал? Вряд ли больше, чем очередной интернет-магазин, но кого это останавливало! '''Никита Шультайс''' (http://shultais.ru) расскажет эту старую историю на новый лад.

Сегодня каждый более-менее продвинутый пользователь желает иметь свой сайт. Одни устанавливают готовые системы управления web-содержимым (CMS), вторые пишут все с нуля, а третьи – используют web-каркасы (framework), позволяющие создавать отличные динамические web-сайты без особых усилий.
''Django'' как раз и является таким каркасом, написанным на ''Python''. К
числу задач, с которыми он помогает справиться, относятся:

* Создание и обработка форм;
* Разделение логики и представления с помощью мощной системы шаблонов;
* Добавление, поиск, извлечение и удаление записей из базы данных, в объектно-ориентированном стиле (ORM);
* Обработка URL с помощью регулярных выражений;
* Автогенерация интерфейса администратора (в просторечии, «админки»);
* Аутентификация и авторизация пользователей;
* Кэширование как отдельных элементов, так и целых страниц;
* Интернационализация сайта;
* Создание и отправка сообщений по e-mail;
* Тестирование;
* Работа с сессиям, HTTP-запросами и cookie.

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

===На исходную!===

Дистрибутив ''Django'' можно скачать с официального сайта (http://www.djangoproject.com) или взять с '''LXFDVD'''. Желательно использовать
версию из репозитория (0.97), но можно ограничиться и последним стабильным релизом – 0.96. Кроме того, для связи с сервером ''MySQL'' нам
понадобится ''MySQLdb'' версии 1.2.1p2 или выше. После получения ''Django'',
распакуйте архив, перейдите в появившийся каталог и выполните

sudo python setup.py install
[ваш пароль]

При желании, можете заменить ''sudo'' на ''su'' и ввести пароль суперпользователя.

Для начала работы нам нужно создать «проект», в котором будут
храниться все наши файлы. Для этого перейдите в директорию, в
которой вы собираетесь хранить проект (например, '''/var/www'''), и
дайте команду

python /путь/к/django/bin/django-admin.py startproject myproject

после выполнения которой в текущем каталоге появится поддиректория с именем '''myproject'''.

Рассмотрим ее внутреннюю структуру:
myproject/
__init__.py
manage.py
settings.py
urls.py

'''__init__.py''' – это специальный (как видно по двум подчеркиваниям в
имени) файл, который указывает на то, что данный каталог является
модулем (пакетом) языка ''Python''; '''manage.py''' – утилита, позволяющая
управлять вашим проектом. '''Settings.py''' содержит его настройки, а '''urls.py''' – это так называемый «файл URL-карт». В нем указывается, какому адресу какой код соответствует.

Для запуска проекта выполните из его директории команду

{{Врезка|Содержание=[[Изображение:LXF105_86_1.jpg|Рис. 1|300px]]Рис. 1. Оно работает, следовательно, существует!|Ширина=300px}}

python manage.py runserver

Она запустит встроенный в ''Django'' web-сервер, предназначенный
специально для разработки сайтов. Сервер стартует на локальном
хосте на порту 8000 и, если все пройдет успешно, вы увидите в консоли следующее сообщение:

Validating models...
0 errors found.
Django version 1.0, using settings 'myproject.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Направив свой любимый web-браузер по адресу
http://127.0.0.1:8000/:, вы получите нечто похожее на рис. 1.

===Настроим ''Django''===

Как уже говорилось выше, основные настройки вашего проекта хранятся в файле '''settings.py'''. Откроем его и найдем строку '''DATABASE_ENGINE = ''''': она отвечает за СУБД, которую мы будем использовать в нашем проекте. Поскольку мы выбрали ''MySQL'', изменим эту строку
на '''DATABASE_ENGINE = 'mysql''''. Далее, в '''DATABASE_USER''' укажем
имя пользователя вашей базы данных (заметьте, что у него должны
быть права на создание таблиц в БД), а в '''DATABASE_PASSWORD''' –
его пароль. Если сервер баз данных запущен на локальном хосте и на
порту по умолчанию, параметры '''DATABASE_HOST''' и '''DATABASE_PORT'''
можно оставить пустыми. В поле '''DATABASE_NAME''' введите имя базы
данных (не путайте его с именем СУБД!), которую будет использовать
проект. Да, и не забудьте создать ее перед использованием. В частности, для ''MySQL'' это делается так:

mysql --user=username --password=password
mysql > CREATE DATABASE `myproject_base` DEFAULT CHARACTER
SET utf8 COLLATE utf8_general_ci;

Здесь '''username''' – имя пользователя, который имеет доступ к
СУБД, '''password''' – его пароль, '''myproject_base''' – название БД, в которой будут храниться данные нашего проекта.

Перейдем к секции '''INSTALLED_APPS''', которая отвечает за установленные в нашем проекте приложения. По умолчанию, команда
startproject создает проект с четырьмя предустановленными приложениями общего назначения:

INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
)

Каждое из них отвечает за свою специфическую область:

* '''django.contrib.auth''' – система аутентификации;
* '''django.contrib.contenttypes''' – каркас типов содержимого;
* '''django.contrib.sessions''' – работа с сессиями;
* '''django.contrib.sites''' – каркас, позволяющий управлять несколькими сайтами из одной установки ''Django''.

Хотя эти приложения и перечислены в '''INSTALLED_APPS''', они еще не установлены окончательно, так как для них не созданы таблицы в
базе данных. Для завершения инсталляции, выполните следующий
код:

python manage.py syncdb

Данная команда создаст необходимые таблицы в базе данных,
после чего вам будет предложено определить суперпользователя –
администратора сайта:

You just installed Django's auth system, which means you don't have any
superusers defined.
Would you like to create one now? (yes/no):

Ответьте «'''yes'''», а затем следуйте инструкциям, заполняя поля
имени, '''e-mail''' и пароля для суперпользователя. Вот теперь система
полностью установлена.

===Создание приложения===

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

python manage.py startapp news

где '''news''' – имя нашего приложения; его-то мы и будем разрабатывать
на протяжении всех четырех уроков. Задача '''news''' достаточно стандартна: это публикация, просмотр и обсуждение новостей. По традиции, давайте начнем с изучения структуры нашего приложения:

news/
__init__.py
models.py
views.py

Как видно, оно состоит из трех файлов: '''__init__.py''', с которым
мы уже встречались выше, '''models.py''' – места для описания моделей
(схем таблиц в БД с некоторыми дополнительными данными) и '''views.py''', определяющего представления (код, который отвечает за логику
вашего приложения).

Работа с приложением обычно начинается с создания моделей,
поэтому откройте файл '''models.py''' в вашем любимом текстовом
редакторе и наберите следующий код:

from django.db import models
class News(models.Model):
title = models.CharField(max_length=70)
description = models.CharField(max_length=255)
pub_date = models.DateTimeField()
text = models.TextField()
class Comment(models.Model):
news = models.ForeignKey(News)
username = models.CharField(max_length=70)
text = models.TextField()
pub_date = models.DateTimeField(auto_now_add=True)

Мы создали две модели: первая ('''News''') отвечает за саму новость,
а вторая ('''Comment''') – за комментарии к ней.

Каждая модель (таблица, в терминах БД) представлена классом,
который наследуется от '''django.db.models.Model'''. Все поля представляются объектом класса '''models.*Field'''. Имя поля используется как
для создания столбцов в таблице БД, так и для доступа к данным
через ''Django ORM'', поэтому для упрощения чтения и написания кода
старайтесь давать полям осмысленные названия.

Начнем с поля '''title''' класса '''News'''. Запись '''models.CharField''' указывает на то, что это поле является символьным, а '''max_length=70''' говорит, что мы можем записать в него максимум 70 символов. Соответственно,
'''DateTimeField''' означает, что поле будет содержать дату в формате
'''DateTime''' (атрибут '''auto_now_add''' в '''pub_date''' в классе '''Comments''' указывает на то, что поле при создании записи будет автоматически заполняться текущим временем), '''TextField''' – это обычный текст.

Особое значение имеет '''ForeignKey''', который говорит, что поле
является внешним ключом (в связке «один-ко-многим») по отношению к модели (таблице) '''News'''. То есть, у каждого комментария
есть поле news, хранящее номер новости, к которой относится комментарий.

Теперь, когда модели созданы, приложение можно установить.
Этот процесс проходит в два этапа:

# Инициализация приложения в '''settings.py''' в разделе '''INSTALLED_APPS''';
# Создание таблиц в базе данных.

Откройте '''settngs.py''' и добавьте к '''INSTALLED_APPS''' строку ''''myproject.news''''. Заметьте, что '''INSTALLED_APPS''' – это кортеж ''Python'',
поэтому будьте внимательны с синтаксисом. Теперь перейдите в корень нашего проекта и наберите команду:

python manage.py syncdb

Она, как мы уже знаем, создаст необходимые таблицы в БД.

===Автогенерация «админки»===

{{Врезка|Содержание=[[Изображение:LXF105_88_1.jpg|Рис. 2|250px]]Рис. 2. Врата в административный раздел ''Django''. |Ширина=250px}}

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

Для того, чтобы подключить систему администрирования, нужно выполнить несколько шагов (в той очередности, в которой они представлены ниже):
# Добавить '''django.contrib.admin''' в '''INSTALLED_APPS''' вашего проекта.
# Выполнить ''python manage.py syncdb'' из корневого каталога проекта.
# Открыть myproject/urls.py и раскомментировать строку
# (r'^admin/', include('django.contrib.admin.urls')),

После этого запустите web-сервер (''python manage.py runserver'') и перейдите по адресу http://127.0.0.1:8000/admin/. Вы увидите форму авторизации для входа в систему администрирования:

{{Врезка|Содержание=[[Изображение:LXF105_88_2.jpg|Рис. 3|300px]]Рис. 3. Административный интерфейс ''Django''.|Ширина=300px}}

Введите имя и пароль суперпользователя, и – добро пожаловать
в «админку» ''Django''! На ее главной странице (рис.3) можно видеть
несколько областей:
* Вверху – панель приветствия, просмотра документации, изменения пароля и выхода из системы.
* Посередине слева – установленные приложения (название и модели) и действия, которые можно совершать с ними (добавление и изменение записей).
* Посередине справа – последние действия, которые были произведены в «админке».

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

class Admin:
pass

Сохраните файл моделей и перезагрузите страницу. Теперь наше
приложение должно быть доступно в «админке». Если бы мы использовали какой-то другой HTTP-сервер (например, ''Apache''), нам бы
пришлось бы перегружать его после каждого изменения в исходных
кодах. А это очень неудобно, особенно когда процесс разработки в
самом разгаре.

Ну что, добавим первую новость? Найдите на странице строку
'''Newss''' (это не опечатка – ''Django'' автоматически добавляет окончание
'''-s''' к именам моделей) и перейдите по ссылке '''Add'''. Откроется форма для
добавления новости:

Заполните все поля и нажмите кнопку '''Save''' [Сохранить]. Вы будете перенаправлены на страницу списка доступных новостей. Пока что он состоит из одной новости, которую мы только что добавили, но
как только их станет больше, возникнет одно неудобство: все новости
будут отображаться как '''News object''' [Объект класса News], и мы быстро
запутаемся, где какая. Чтобы видеть заголовок новости, изменим
'''models.py''' приложения '''news''', добавив в модель '''News''' следующий код:

{{Врезка|Содержание=[[Изображение:LXF105_88_3.jpg|Рис. 4|300px]]Рис. 4. Форма для добавления новостей.|Ширина=300px}}

def __unicode__(self):
return self.title

Обновите страницу – у новостей появятся осмысленные названия.
Давайте добавим еще одну новость, но на этот раз оставим поле '''Title'''
пустым, в поле '''Date''' напишем слово «дата», а в поле '''Time''' – «время»
и попробуем сохранить ее в базе. Что, ''Django'' ругается? И правильно делает – нечего оставлять поля пустыми. Обратите внимание, что
прочие поля (которые были введены верно) остались нетронутыми, и
вам осталось только исправить ошибки, а не заполнять форму заново, как это часто бывает на сайтах «средней руки».

===Публикация в сети===

Хорошо, создавать записи («объекты» в терминах ''Django ORM'') мы научились, а дальше-то что? Дальше нам надо разместить их на сайте – ведь
от новостей, которые никто не видит, нет пользы. Чтобы сделать это,
нужно опять пройти через несколько несложных этапов:

* Создать представление (функцию, отвечающую за логику), которое будет выбирать нужные нам объекты из базы данных и обрабатывать их в соответствии с нашими потребностями;
* Создать шаблон, который будет отвечать за стиль отображения данных;
* Передать выбранные объекты в шаблон;
* Связать URL с нашим представлением.

Порядок тут особой роли не играет. К тому же, за разные действия
могут отвечать разные люди: за представления – программист, за
шаблоны – дизайнер.

Начнем с представлений. Они, как мы знаем, хранятся в файле
'''views.py''' в корне каждого приложения. Перейдите в директорию '''news'''
и откройте файл '''views.py'''. Затем добавьте следующий код (разумеется,
номера строк приведены исключительно для удобства):

<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
from datetime import datetime
from django.template.loader import get_template
from django.http import HttpResponse
from django.template import RequestContext

from news.models import News

def last_news(request):
news = News.objects.filter(
pub_date__lte=datetime.now()).order_by(«-pub_date»)[:10]
template = get_template(“news/last_news.html”)
context = RequestContext(request, {
“last_news”:news,
})
return HttpResponse(template.render(context))
</source>

Первые четыре строчки загружают необходимые функции и классы:
* '''datetime''' – тип для работы с датой и временем;
* '''get_template''' – функция, которая ищет и возвращает шаблон;
* '''HttpResponse''' – основной HTTP ответ;
* '''RequestContext''' – специальный класс, с помощью которого можно определять переменные, используемые в шаблонах.

Далее (строка 6) происходит импорт класса модели наших новостей. С
его помощью мы получаем доступ к ''Django ORM'', и, следовательно, к объектам в нашей базе данных.

Функция '''last_news''' – это и есть представление. Заметьте, что она принимает обязательный аргумент '''request''', через который передаются параметры HTTP-запроса.

Что же происходит при вызове '''last_news'''? Сначала мы извлекаем
объекты из базы данных (строки 9–10). Конструкция '''filter''' ограничивает
выборку по какому-то условию, в нашем случае '''pub_date__lte=datetime.now()''' означает, что дата публикации новостей должна быть меньше или
равна ('''lte''' – «less than or equal to») текущей дате ('''datetime.now()'''). Это
позволит нам создавать новости «на будущее», и они не будут отображаться на сайте до тех пор, пока дата их публикации не станет раньше или
равной текущей. '''order_by''' – сортирует записи по определенному столбцу,
в нашем случае – '''pub_date''', а знак минус означает, что сортировка будет
произведена в обратном порядке. И наконец '''[:10]''' – срез, который указывает, что извлекать нужно только 10 последних записей.

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

Ну и, наконец, в последней строке мы возвращаем стандартный HTTP-
ответ, в который передаем готовый заполненный шаблон. Вот только... где
взять шаблон?

===Шаблоны===

Для начала подготовим базовый шаблон – '''index.html'''. Создадим в корне
нашего проекта каталог media для хранения статичных файлов (изображений, шаблонов, стилей и т.д.), а уже в '''media''' – подкаталог '''templates''', в
который и поместим файл '''index.html''' со следующим содержимым:

<html>
<head><title>My site</title></head>
<body>
<nowiki><a href=“/news/”>News</a><br/></nowiki>
{% block application %}
Welcome to site.
{% endblock %}
</body>
</html>

Шаблон – это обычный текстовый файл, содержащий специальные
конструкции языка шаблонов ''Django''. В '''index.html''' содержится только одна
конструкция, которая определяет блок '''application''' (строки 6-8). Она называется «тэгом», причем тэг начинается с '''{%''', а заканчивается '''%}'''. Внутри
этого блока находится приветствие, как это часто бывает на сайтах. ''Django''
еще не знает, где искать шаблон, поэтому откроем '''settings.py''', найдем кортеж '''TEMPLATE_DIRS''' и добавим в него строку '''/path/to/project/myproject/media/templates/''', где '''/path/to/project''' – путь до вашего проекта; у меня
это '''/var/www'''.

{{Врезка|Заголовок=Скорая помощь|Содержание=Если вы не увидели ни одной новости (при условии, что они были добавлены), то скорее всего, вы не попали в нужный часовой пояс. Когда мы вызываем функцию '''datetime.now()''', она возвращает время относительно часового пояса, заданного в переменной
'''TIME_ZONE''' в файле '''settings.py'''. По умолчанию в нем содержится '''America/Chicago'''. Все, что вам нужно – это изменить значение на название вашего часового пояса на английском, например, на '''Asia/Krasnoyarsk'''. Cписок часовых поясов можно найти в директории '''/usr/share/zoneinfo/'''
в файле '''zone.tab'''. |Ширина=200px}}

Теперь, когда базовый шаблон готов, перейдем к шаблону новостей.
Опять же, создадим в директории нашего приложения ('''news''') каталог
'''templates''', внутри '''templates''' создадим каталог '''news''', а в '''templates/news'''
добавим файл '''last_news.html'''. Заметьте, что имя файла шаблона совпадает с именем представления, к которому оно относится. Так делать не
обязательно – это просто правило хорошего стиля.

Сам файл '''last_news.html''' может иметь следующий вид:
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
{% extends “index.html” %}

{% block application %}
{% for news in last_news %}
<nowiki>[{{ news.pub_date|date:»d.m.Y»}}]</nowiki>
<nowiki><strong>{{ news.title }}</strong></nowiki>
<nowiki><p>{{ news.description }}</p></nowiki>
{% endfor %}

{% endblock %}
</source>
Первая строка означает, что шаблон новости расширяет шаблон '''index.html'''. В строке 3 мы открываем блок '''application''' (он, как вы помните,
идет из '''index.html''') и переопределяем его. В строках 5–8 мы создаем цикл
по объектам '''last_news''' (которые были переданы в шаблон из нашего представления). В строках 6–8 мы вставляем данные, относящиеся к каждой
новости, из '''last_news'''. Помимо тэгов, в шаблоны можно помещать переменные, имена которых будут заменены их значениями. Для этого используется конструкция '''<nowiki>{{ имя_переменной }}</nowiki>'''. В строке 7 мы обращаемся
к переменной '''news''', но каждая новость имеет несколько полей (в соответствии с тем, что мы определили в '''models.py'''), поэтому мы указываем
конкретное поле – '''title''', что в конечном счете выведет заголовок новости.
Особое внимание нужно обратить на запись в строке 6, где мы не просто
обращаемся к дате публикации новости '''news.pub_date''', но и применяем
фильтр форматирования '''|date:«d.m.Y»''', который позволяет вывести дату
в более традиционном для России виде.

Последнее, что нам осталось – это связать URL с представлением.
Откроем '''urls.py''' и после строки

(r'^admin/', include('django.contrib.admin.urls')),

добавим

(r'^news/', 'news.views.last_news').

Данный код означает, что при переходе к http://www.mydomain.ru/news/ будет выполняться представление '''news.views.last_news'''.

Затем допишите в самый конец файла

urlpatterns += patterns('django.views.generic.simple',
(r'^$','direct_to_template', {'template': 'index.html'}),)

Эта запись говорит, что при обращении к корню сервера должен
использоваться шаблон '''index.html'''.

Ну все, наш сайт готов. Запустите сервер разработчика и перейдите в
вашем браузере по адресу http://127.0.0.1:8000/. Кликните по ссылке '''News'''
и получите самые свежие новости! '''LXF'''

LXF106:Django

2009-08-31T14:51:41Z

Shultais: Добавлена ссылка на сайт автора

: '''''Django''''' Разрабатываем динамические web-приложения современным способом[[Категория:Учебники]]

==Личная блогосфера==

{{Цикл/Django}}

: '''ЧАСТЬ 2''' Новостной портал из прошлого номера журнала легко превратить в мини-блог, предоставив посетителям возможность оставлять комментарии. Но что делать с троллями и спамерами? '''Никита Шультайс''' (http://shultais.ru) во всем разберется.

В прошлый раз мы научились создавать простые ''Django''-приложения, добавили несколько записей в базу данных и вывели на сайт заголовок, дату и описание для последних десяти новостей. А как быть с теми, кто пожелает прочитать текст
сообщения целиком?

Правильно, нужно снова создавать представления и шаблоны.
Но для начала, усовершенствуем наши URL-карты.

===Добавим гибкости===

Откройте файл '''urls.py''' (как вы помните, именно он устанавливает
соответствие между URL-адресами и представлениями) и замените строку

(r'^news/', 'news.views.last_news')

на

(r'^news/', include('news.urls'))

Теперь при переходе к '''news/''' будут подгружаться URL-карты,
относящиеся к приложению. Это позволит нам работать с новостной системой, не выходя за рамки директории news. Далее, нужно
составить URL-карты приложения: создайте файл '''news/urls.py''' следующего содержания:

<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
from django.conf.urls.defaults import *
urlpatterns = patterns('news.views',
url(r'^$','last_news',name = 'news.last_news'),
url(r'^(?P<news_id>\d+)/$','news_detail',name = 'news.news_detail'),
)
</source>

Что происходит при обращении к http://mysite.com/news/? Сначала часть URL ('''news/''') ищется в главном файле URL-карт, где
обнаруживается соответствие. Затем система считывает URL-карты,
отвечающие за конкретное приложение (благодаря '''include('news.urls')''') и продолжает поиск, откинув уже найденный шаблон. Так как
после '''news/''' ничего нет, ''Django'' остановится в строке 3 файла '''news/urls.py''' и выполнит представление '''news.views.last_news''', которое мы
создали на прошлом уроке.

Рассмотрим '''news/urls.py''' подробнее. Во второй строке есть интересная запись – '''news.views''', которая указывает ''Django'', что нужно
задействовать представления из одноименного модуля; это позволяет сэкономить место при наборе URL-карт и облегчает чтение
кода. Строки 3 и 4 – это URL-карты особого формата. Они обернуты функцией '''url()''', принимающей три (точнее сказать – до пяти)
аргументов:

* первый (позиционный обязательный) – регулярное выражение;
* второй (позиционный обязательный) – имя представления, которое будет выполняться;
* третий (именованный необязательный) – имя URL-карты. Оно должно быть уникальным не только для приложения, но и для всего проекта, и в нашем случае состоит из двух частей: имени приложения и представления (это не единственный вариант). Часто возникают ситуации, когда одно представление обслуживает несколько URL-адресов, но имя каждой URL-карты всё равно должно быть уникальным. Скажем, если представление view может добавлять или изменять объекты, в зависимости от URL, то карты могут называться '''app.view.add''' и '''app.view.change'''.

{{Врезка|Заголовок=Скорая помощь|Содержание=Если вы взглянете на наши модели, то увидите, что поля первичного ключа – '''id''' – в них
нет, однако в примере с тегом '''url''' мы используем '''news.id''', как ни в чем не бывало. Все верно – ''Django'' сам создает первичные ключи для каждой модели.|Ширина=200px}}

Обратите внимание на конструкцию ('''?P<news_id>\d+''') в строке 4.
Она совпадает с числом ('''\d+'''), захватывает его и помещает в переменную '''news_id''', которая затем передается в представление.

Хотя картам и не обязательно давать имена, это очень сильно упрощает жизнь
разработчика и делает приложение переносимым. Поэтому откройте файл '''news/templates/news/last_news.html''' и измените
строку:

<nowiki><strong>{{ news.title }}</strong></nowiki>

на

<nowiki><strong>
<a href=”{% url news.news_detail news_id=news.id %}”>{{ news.title }}</a>
</strong></nowiki>

В качестве значения атрибута '''href''' мы вставили тег '''url''' системы шаблонов
''Django''. Ему передаются имена URL-карты
и объявленной нами переменной – '''news_id'''. Значение '''news_id''' присваивается первичному ключу новости, которую хотим
просмотреть.

Теперь, когда ''Django'' будет компилировать наш шаблон, '''{% url news.news_detail news_id=news.id %}''' заменится на http://mysite.com/news/1/ для новости с номером 1, и так далее. Если же вы решите модифицировать URL-
карты, например, переименовав news/ в главном файле URL-карт
в '''supernews/''', то система автоматически скорректирует все ссылки,
и сайт продолжит работать. Не забудьте только отредактировать
файл '''media/templates/index.html''', поправив:

<nowiki><a href=”/news/”>News</a></nowiki>

на

<nowiki><a href=”{% url news.last_news %}”>News</a></nowiki>

Если вы решите опробовать возможность автоматической генерации URL, не дожидаясь конца урока, то потребуется также добавить в файл '''news/views.py''' представление-заглушку для нового типа URL,

def news_detail(requets,news_id):
pass

В противном случае автогенерация работать не будет.

===Создаем форму===

{{Врезка|Содержание=[[Изображение:LXF106_79_1.jpg|Рис. 1|300px]]Рис.1. Вот что должно получиться в итоге.|Ширина=300px}}

Продолжим развитие нашего приложения. Сейчас мы создадим
представление и шаблон, с помощью которого можно просматривать детали новости, а также добавлять комментарии. Первым
делом нужно реализовать форму для комментариев (рис.1), и,
как вы могли догадаться, ''Django'' поможет нам в этом непростом
деле. Дистрибутив ''Django'' содержит целых две системы обработки
форм: '''forms''' (старую) и '''newforms''' (новую). Мы будем пользоваться
последней, так как она более удобна и имеет больше возможностей. К тому же в версии 1.0 разработчики удалят старую библио
теку, оставив только '''newforms''' (которая будет переименована в
'''forms''').

Формы очень удобно хранить в файле '''forms.py''' в директории приложения. Создайте его и наберите код:

<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
# -*- coding: utf-8 -*-
from django import newforms as forms
class CommentForm(forms.Form):
username = forms.CharField(label=”Имя”,required=True,
widget=forms.TextInput(attrs={
'size':'30',
'maxlength':'255'}))
text = forms.CharField(label=”Текст”,required=True,
widget=forms.Textarea())
</source>

{{Врезка|Заголовок=Все еще сомневаетесь?|Содержание=Приведем два основных преимущества отделения URL-карт уровня приложений от главной карты сайта:

* '''Переносимость''' Теперь, если мы хотим добавить наше приложение в другой проект, нужно только скопировать директорию с ним в корень проекта, вписать его в '''INSTALLED_APPS''' и включить '''news/urls.py''' в главный файл '''urls.py'''. Если автор приложения расширит функциональность (например, добавит версию для печати), достаточно будет обновить файлы внутри директории '''news''', не заботясь о добавлении или изменении URL-карт.
* '''Удобная работа с картами'''. В реальных проектах количество приложений может достигать 20 и больше, и каждое из них может содержать 10–20 внутренних карт. Если бы мы оформляли все URL-карты в одном файле, то его размер составил бы около 400 строк, а следовательно, возросла бы вероятность ошибки.|Ширина=200px}}

Каждая форма представлена классом ''Python'', унаследованным
от '''forms.Form'''. Она содержит набор полей, являющихся объектами
класса '''forms.*Field'''. Так, в строках 4-7 определяется поле '''username'''
типа '''CharField''' – символьное. Атрибут '''required''' указывает, что мы
не можем оставить его пустым. Далее следует определение «виджета», то есть органа управления, который будет отображаться на
web-странице. Виджет связан с определенным элементом '''HTML'''-формы, например, '''<select>, <input>''' или '''<textarea>'''. Каждый класс
поля имеет свой стандартный виджет, но мы можем переопределить или расширить его, добавив дополнительные атрибуты.
Виджетом по умолчанию для '''CharField''' является '''TextInput (<input type=»text»>)''', здесь мы задаем ему атрибуты '''size''' и '''maxlength'''. В
строках 8-9 определяется поле '''text''', которое также является символьным, но, поскольку одна строка плохо подходит для ввода
комментария, мы назначаем '''text''' виджет '''Textarea()''', соответствующий '''HTML'''-тегу '''<textarea>'''. Обратите внимание на атрибуты '''label:''' они содержат поясняющий текст, который выводится около элемента экранной формы. Так как мы используем кириллицу, необходимо указать кодировку – это делается в первой строке. Я предпочитаю UTF-8.

Теперь пришло время заменить и нашу заглушку (если, конечно,
вы ее создали):

<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
def news_detail(request, news_id):
news = News.objects.get(pk=news_id)
if request.method == 'POST':
form = CommentForm(request.POST)
if form.is_valid():
comment = Comment(
news=news,
username = form.cleaned_data['username'],
text = form.cleaned_data['text'])
comment.save()
return HttpResponseRedirect(
reverse('news.news_detail',kwargs={'news_id':news_id}))
else:
form = CommentForm()

comments = Comment.objects.filter(news=news).order_by(“pub_ date”,”id”)
comment_count = comments.count()

template = get_template(“news/news_detail.html”)
context = RequestContext(request, {
“news”:news,
“form”:form,
“comment_count”:comment_count,
“comments”:comments
})
return HttpResponse(template.render(context))
</source>

Сразу стоит обратить внимание на то, что в представление передается дополнительный аргумент '''news_id''', имя которого совпадает с идентификатором переменной, захватываемой при обработке
регулярного выражения в файле '''news/urls.py'''. Во второй строке
мы извлекаем новость, а так как нам нужен только один объект,
то используем для этого функцию '''get()''', передавая ей '''news_id'''
в качестве именованного аргумента '''pk''' ('''Primary Key''', первичный ключ). Дальше следуют два блока: для '''POST-''' (строки 4-12), и
'''GET-'''запросов (14). В строке 3 проверяется, как именно произошло
обращения к данному URL. В случае '''GET''' мы просто создаем объект
формы с пустыми полями.

Если же данные были получены посредством запроса '''POST''', они
передаются в форму. Далее идет проверка на корректность (строка
5): мы убеждаемся, что заполнены все поля. В случае успеха создается объект комментария. Первый параметр – это новость, к которой
он относится, аргументам '''username''' и '''text''' присваиваются очищенные
(то есть преобразованные к определенному типу: '''unicode''' для текста,
'''datetime''' для даты и так далее) данные из полей формы. В 10-й строке
объект сохраняется в БД, а в строках 11–12 мы осуществляем перенаправление. Функция '''reverse''' – это аналог тега url в шаблонах. Она принимает имя URL-карты, а в словаре '''kwargs''' должны содержаться требуемые аргументы, причем переменной '''news_id''' присваивается номер
текущей новости... Проще говоря, мы обновляем страницу. Если же
проверка в строке 5 не проходит, то мы автоматически отправляемся к
строке 15 с формой, где уже заполнены некоторые поля, а для пустых
созданы сообщения об ошибках.

Обратимся к строкам 16 и 17. В первой мы извлекаем все комментарии, относящиеся к новости, а во второй получаем их количество, причем функция '''count()''' генерирует '''SQL'''-конструкцию '''COUNT''',
которая работает очень быстро.

Строки 19-26 рассматривались на прошлом уроке, и сейчас мы
не будем на них останавливаться. Лучше рассмотрим шаблон '''news/templates/news/news_detail.html''' – он может иметь такой вид:

<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
{% extends “index.html” %}

{% block application %}

<h1>{{ news.title }}</h1>
<p> {{ news.text }} </p>
{% if comment_count %}
<h3>Комментариев: {{ comment_count }}</h3>
{% for comment in comments %}
<div>
<strong>{{ comment.username }}</strong> пишет:<br/>
{{ comment.text }}<br/>
Дата {{ comment.pub_date|date:”d.m.Y” }}
</div>
<br/><br/>
{% endfor %}
{% else %}
<h3>Комментариев нет</h3>
{% endif %}

<h3>Оставить комментарий:</h3>
<form action=”.” method=”POST”>
<table>{{ form }}</table>
<input type=”submit”/>
</form>

{% endblock %}
</source>

Обратите внимание на строку 7, с которой начинается новый для нас тег – '''{% if %}'''. Он принимает логическую (а поскольку в ''Python'' все числовые значения и строки, которые не равны нулю и не пусты, эквивалентны True, то практически любую) переменную. В строке 17
расположена вторая часть тега – альтернативный блок '''{% else %}''' и,
наконец, в строке 19 тег закрывается. Разумеется, альтернативный
блок можно опустить.

Хотя ''Django'' берет на себя бремя генерации форм, некоторую
часть кода приходится писать вручную. Так, в строке 22 мы определяем форму, а в строке 23 создаем таблицу, в которую она будет
помещена. Дело в том, что по умолчанию при вызове объекта формы все виджеты оборачиваются в '''<nowiki><tr> и <td></nowiki>'''. Это поведение можно
исправить, заменив '''form''' на '''form.as_ul''' или '''form.as_p''', которые которые возвращают ее в виде ненумерованного списка '''<nowiki>(<ul>)</nowiki>''' и параграфов '''<nowiki>(<p>)</nowiki>''', соответственно. Кнопка для отправки формы создается
в строке 24.

Теперь, когда мы создали шаблон и представление для просмотра текста новости и добавления комментариев, осталось только
импортировать необходимые классы и функции в представление
'''news/views.py''':

<source lang=python>
from news.models import News
from news.forms import CommentForm
from django.http import HttpResponseRedirect
from django.core.urlresolvers import reverse
</source>

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

===Плохой песик, плохой!===

Когда ваши новости комментируют объективно – это прекрасно,
но мир неидеален и пока не искоренены спам и флуд, вам придется модерировать сообщения, оставленные посетителями. Наша
система не поддерживает пре-модерацию; конечно, в реальных
проектах так поступать не стоит. Но и у нас не всё потеряно – мы
можем:

* Модерировать комментарии из административного интерфейса
* Делать это прямо с сайта.

{{Врезка|Содержание=[[Изображение:LXF106_81_1.jpg|Рис. 2|300px]]Рис. 2. Пользователи и группы ''Django''.|Ширина=300px}}

Первый вариант настолько прост, что мы даже не будем на
нем останавливаться, но прежде чем перейти ко второму случаю,
поговорим о системе прав ''Django''. С главной страницы «админки»
можно перейти в разделы управления пользователями и группами (рис.2).

Каждый пользователь и группа могут иметь определенные
права доступа, которые описываются в моделях. По умолчанию,
модель предоставляет три разрешения: добавить, изменить и удалить объект из базы данных. Если вы перейдете на страницу редактирования пользователя в «админке», то в разделе '''Permissions > User permissions''' увидите список прав доступа, причем в левой
части ('''Available user permissions''') указываются всевозможные права,
известные системе, а в правой ('''Chosen user permissions''') – разрешения, которыми обладает редактируемый пользователь (рис.3).

{{Врезка|Содержание=[[Изображение:LXF106_81_2.jpg|Рис. 3|300px]]Рис. 3. Настройка прав доступа.|Ширина=300px}}

Каждая строка содержит три части: приложение, модель и право доступа в человеко-понятной форме. Например, '''news | comment | Can add comment''' означает, что пользователь может добавлять комментарии в модель '''comment''' приложения '''news'''. Проверку прав доступа
нужно осуществлять на уровне представлений или/и шаблонов. На
уровне моделей она не производится, поэтому комментарии к нашим
новостям могут добавлять любые посетители, даже не имеющие прав
на совершение таких действий.

Условно, всех пользователей системы можно разделить на две
группы: анонимные и авторизованные. Особый случай – это суперпользователь; в ''Django'', как и в Linux, он царь и бог и обладает
всеми возможными правами. Назначить себя суперпользователем
можно, установив галочку напротив поля '''Superuser status'''. Отметим
ещё два поля в разделе '''Permissions''':
* '''Staff status''' – если эта галочка установлена, пользователь может заходить в «админку» ''Django''.
* '''Active''' – если флажок снят, посетителю будет отказано в авторизации, даже когда он верно указывает свои имя и пароль.

Создадим еще одно представление, с помощью которого будем удалять нежелательные комментарии:

<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
@permission_required('news.delete_comment')
def delete_comment(request, news_id, comment_id):
comment = get_object_or_404(Comment,pk=comment_id)
comment.delete()
return HttpResponseRedirect(reverse('news.news_ detail',kwargs={'news_id':news_id}))
</source>

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

from django.contrib.auth.decorators import permission_required

Права доступа в декораторах определяются именем приложения
('''news''') и названием разрешения ('''delete_comment'''). Последнее получается автоматически конкатенацией действия ('''delete''') и модели.
Обратите внимание на строку 3: в ней мы извлекаем из базы данных единственный объект, но используем сокращение '''get_object_or_404()''', которое возвращает страницу 404 в случае отсутствия объекта. Не забудьте импортировать функцию '''get_object_or_404()''' в
ваше представление до её использования:

from django.shortcuts import get_object_or_404

Теперь нам нужно связать URL с представлением:

url(r'^(?P<news_id>\d+)/(?P<comment_id>\d+)/delete/$','delete_comment',name='news.delete_comment'),

Давайте расширим наш шаблон: во-первых, незачем показывать
форму анонимным пользователям, во-вторых, следует добавить
ссылку для удаления комментария, если посетитель обладает достаточными правами. Допишите следующий код после строки 10:

{% if perms.news.delete_comment %}
<a href=”{% url news.delete_comment news_id=news.id,comment_id=comment.id %}”>[X]</a>
{% endif %}

Это напоминает использование декораторов, за исключением
обращения к объекту '''perms'''. Теперь напротив каждого комментария
будет присутствовать ссылка для его удаления. Далее, заключите
форму (строки 21-25) в блок '''{% if %}''', чтобы она не отображалась
неавторизованным пользователям.

{% if user.is_authenticated %}
...
{% endif %}

Помимо '''perms''', содержащего права текущего пользователя, в
шаблон передается объект '''user''', предоставляющий доступ к прочим реквизитам: имени пользователя, хэшу пароля, данным о текущем состоянии (анонимный или авторизованный). Например, с помощью:

{% if user.is_superuser %}

можно определить, является ли посетитель суперпользователем.

===Вас взломали!===

Казалось бы, все в порядке, но есть одна тонкость. Спрятав форму
от глаз неавторизованного пользователя, мы не лишили его возможности «заполнять» ее, генерируя HTTP-заголовки вручную – представление ведь осталось прежним! Чтобы закрыть лазейку, нужно перво-наперво импортировать исключение '''Http404''' (страница не найдена):

from django.http import Http404

После проверки метода запроса в файле '''news/views.py''' (строка 3) добавьте конструкцию

if not request.user.is_authenticated(): raise Http404

она выбрасывает исключение, если посетитель неавторизован.

Помимо '''Http404''', можно создавать ответы с различными HTTP-кодами, например, '''HttpResponseForbidden''' (403 – доступ запрещен)
и так далее. Заметьте, что '''Http404''' – это именно исключение и его
нужно возбуждать с помощью '''raise''', тогда как остальные ответы
возвращаются посредством '''return'''.

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

form = CommentForm()

на

form = CommentForm(initial={'username':request.user.username})

поле '''username''' автоматически получит имя текущего авторизованного пользователя.''' LXF'''

LXF107:Django

2009-08-31T14:50:52Z

Shultais: Добавлена ссылка на сайт автора

{{Цикл/Django}}
== В гостях хорошо, а дома лучше ==
: ''ЧАСТЬ 3 В мире существуют языки, отличные от английского, и компьютеры попроще IBM Roadrunner. '''Никита Шультайс''' (http://shultais.ru) покажет, как Django справляется и с тем, и с другим.''

До сих пор мы созерцали «админку» на английском языке,
однако ее русификация – тоже не проблема. Для этого нужно всего лишь добавить в кортеж MIDDLEWARE_CLASSES в
файле settings.py следующую строку:
'django.middleware.locale.LocaleMiddleware',
Она вызывает специальный обработчик, который отыскивает
нужный перевод. Чтобы определить, какой язык требуется, Django
делает следующее:
# Ищет в текущей сессии пользователя значение ключа django_language.
# Если поиск завершился провалом, Django изучает HTTP-заголовок Accept-Language, генерируемый вашим браузером в соответствии с локальными настройками.
# Наконец, если ничего не было найдено, используется значение переменной LANGUAGE_CODE, установленное в файле settings.py.

Если основной аудиторией вашего сайта будут русскоязычные пользователи, имеет смысл присвоить переменной LANGUAGE_CODE в файле settings.py значение ru.

Основным понятием, которым оперирует Django при интернационализации, являются строки перевода – помеченный особым
образом текст в ваших исходных кодах или шаблонах. Собственно
процесс перевода реализуется библиотекой gettext, которая входит в состав Python. Чтобы ваше приложение стало доступным на
нескольких языках, нужно пройти несколько этапов:
# Определить строки перевода в исходных текстах и шаблонах.
# Запустить утилиту make-messages.py, которая найдет все строки перевода и создаст из них языковой файл.
# Перевести полученный языковой файл.
# Запустить утилиту mcompile-messages.py, которая скомпилирует языковой файл в формат, пригодный для его дальнейшего использования системой.
При этом предполагается, что строки перевода используют
английский язык.

=== Что переводить? ===
{{Врезка
|Заголовок=Вниманию полиглотов
|Содержание=Сессии в Django полностью основаны на cookie, и если они отключены на клиенте, то могут возникнуть проблемы с переключением языков. Решением является Accept-Language: когда браузер
устанавливает этот HTTP-заголовок, он руководствуется выбранными вами языковыми предпочтениями. Например, в Mozilla
Firefox они находятся в Правка > Настройки > Дополнительно,
на вкладке Общее. В разделе Языки, нажмите кнопку Выбрать
и переместите Английский язык наверх (см. рис. 1). Теперь
Firefox будет считать, что английский вам роднее, и сообщит об
этом Django посредством Accept-Language. Не забудьте вернуть
настройки обратно, дабы не пугаться англоязычных интерфейсов ваших любимых сайтов!
[[Изображение:LXF107 88 1.png|center|thumb|250px|Рис.1. Укажите язык «админки» Django (и не только) в настройках Firefox.]]
|Ширина=300px}}
Для начала давайте разберемся, как помечаются строки перевода
в исходных текстах приложения. Откройте файл news/views.py. В
первую очередь, нужно импортировать функцию ugettext() (она, в
отличии от gettext(), отлично справляется с Unicode):
from django.utils.translation import ugettext as _
Как можно заметить, для импортированной функции мы создали псевдоним: _ (подчеркивание). Это было сделано для повышения удобочитаемости кода, содержащего большое число строк перевода.

Затем, давайте передадим функции _() текст, который
мы собираемся перевести, и присвоим результат переменной
application_name:
application_name = _("news")
Поместим эту строку в представление last_news, а переменную
application_name передадим в шаблон:
<pre>context = RequestContext(request, {
"last_news":news,
"application_name":application_name
})</pre>
Теперь откройте шаблон news/templates/news/lats_news.html и
добавьте имя нашего приложения в строку 4:
<pre>1-3 ...
4 <h2>{{ application_name }}</h2>
5-...</pre>
В шаблон news/templates/news/news_detail.html нужно
импортировать тэги интернационализации. Для этого в строке 2
напишите:
{% load i18n %}
после чего в шаблоне будет доступен тэг {% trans %} (и не только),
с помощью которого мы будем отмечать строки перевода. Замените
текст в строке 5:
<nowiki>5 <h1>{{ news.title }}</h1></nowiki>
на
<nowiki><h1>{% trans "News" %}<br/>{{ news.title }}</h1></nowiki>
Думаю, вы уже догадались, как все это работает. В соответствии
с нашим планом, настало время запустить специальную утилиту и
создать языковый файл.

=== Вавилонское смешение ===
Для начала, откройте терминал, перейдите в директорию приложения news и создайте в ней каталог locale:
cd news
mkdir locale
Утилита make-messages.py находится в поддиректории bin установки Django. Вызовите ее со следующими параметрами:
python /путь/до/django/bin/make-messages.py -l ru
Если все пройдет удачно, в директории news/locale будут созданы дополнительные каталоги ru/LC_MESSAGES, а в них – языковый
файл django.po, который и нужно переводить. Откройте его в любом
текстовом редакторе (для удобства можно пользоваться программой KBabel из KDE). Вы увидите следующее:
<pre>#: views.py:23
msgid "news"
msgstr ""
#: templates/news/news_detail.html:5
msgid "News"
msgstr ""</pre>
Первая запись в каждом блоке указывает место, где была найдена строка перевода, далее идет текст, который нужно перевести,
и наконец, сам перевод (у нас его пока нет). Мы специально создали два варианта слова «news» – с заглавной буквы и с маленькой,
чтобы наглядно продемонстрировать, что система воспринимает
их как разные слова. Заполните пустые строки русскими «новости» и «Новости». После того, как с переводом языкового файла
будет покончено, скомпилируйте его. Для этого воспользуйтесь
утилитой compile-messages.py, которая опять же входит в состав
Django:
python /путь/до/django/bin/compile-messages.py
В каталоге LC_MESSAGES появляется скомпилированный языковой файл django.mo. Все готово: наше приложение теперь поддерживает два языка.

=== Смена языка на сайте ===
Мы уже выяснили, как задать язык для клиентов с отключенными
cookie, однако далеко не все пользователи догадаются так поступить, да и у большинства ваших посетителей cookie так или иначе
включены. Значит, чтобы сменить язык сайта, нужно только переписать cookie, которые за это отвечают. И опять Django не оставляет
нас в беде. Для начала откроем главный файл с URL-картами – urls.
py, и после строки
(r'^news/', include('news.urls')),
добавим
(r'^i18n/', include('django.conf.urls.i18n')),
Далее, откроем файл settings.py и добавим следующие
строки:
<source lang="python">TEMPLATE_CONTEXT_PROCESSORS = (
"django.core.context_processors.auth",
"django.core.context_processors.i18n",
"django.core.context_processors.request",
)</source>
Так мы подключим к нашей системе три контекстных процессора,
которые добавляют в шаблоны глобальные переменные для работы с текущим пользователем, переменные языковых настроек и
содержимое HTTP-запроса, соответственно. Откройте файл media/templates/index.html и после тэга <body> добавьте:
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
<form action="/i18n/setlang/" method="post">
<input name="next" type="hidden" value="{{ request.PATH_INFO }}" />
<select name="language">
{% for lang in LANGUAGES %}
<option value="{{ lang.0 }}"
{% ifequal lang.0 LANGUAGE_CODE %}
selected="selected"
{% endifequal%}>{{ lang.1 }}</option>
{% endfor %}
</select>
<input type="submit" value="Go" />
</source>
В строке 1 задается форма, данные из которой будут направлены на встроенное в Django приложение django.views.i18n.set_language, расположенное по адресу /i18n/setlang/ и отвечающее
за смену языка сайта. Оно принимает POST-запрос, содержащий
следующие переменные:
* next – адрес, куда будет перенаправлен пользователь после смены языка. Это, как правило, адрес страницы, на которой мы решили поменять язык. Он содержится в переменной request.PATH_INFO, которую мы передаем в шаблон с помощью контекстного процессора django.core.context_processors.request.
* language – язык, который был выбран.

[[Изображение:LXF107 90 1.png|thumb|150px|Рис. 2. Многообразие языков, поддерживаемых Django.]]
Список языков доступен в переменной LANGUAGES, но если
вы посмотрите на сайт (рис. 2), то увидите огромный перечень,
из которого нам нужны только два языка. Дело в том, что если
в settings.py не определена какая-либо переменная, то ее значение автоматически берется из файла настроек Django – django/conf/global_settings.py, а там представлен кортеж LANGUAGES,
содержащий все языки, поддерживаемые системой: это более 40
наименований (в том числе, языки, в которых символы пишутся
справа налево). Чтобы оставить только те из них, которые нам
действительно необходимы, добавим в файл settings.py следующий кортеж:
<pre>LANGUAGES = (
('en', gettext_noop('English')),
('ru', gettext_noop('Russian')),
)</pre>
не забыв написать перед ним:
gettext_noop = lambda s: s
Теперь, если вы загрузите сайт, вам будут доступны только два
языка. Вернемся опять к нашей форме: в строке 6 вы найдете новый
тэг шаблона ifequal – он сравнивает две переданные переменные, и
если они одинаковы, выполняет код в строке 7.

=== Особенности перевода админки ===
В отличиe от представлений, где мы вызывали функцию ugettext, в
«админке» желательно использовать функцию ленивого (отложенного) перевода ugettext_lazy. Ее главное отличие в том, что перевод
осуществляется не сразу, а в момент использования строки, например, при обработке шаблона в «админке» Django. Импортируйте эту
функцию в файле news/models.py:
from django.utils.translation import ugettext_lazy as _
Каждое поле модели принимает первым позиционным аргументом свое имя, поэтому строку
title = models.CharField(max_length=70)
можно заменить на
title = models.CharField(_('title'),max_length=70)
В дополнение к имени поля можно передать текст справки.
Замените на
description = models.CharField(help_text=_('Not more than 255 symbols.'),max_length=255)
И, наконец, если вам уже надоело слово «News» на главной
странице «админки», измените его на более подходящее. Добавьте
в класс News подкласс Meta (напомню, что он обеспечивает дополнительные настройки модели), а внутри него объявите переменную,
отвечающую за множественное число:
class Meta:
verbose_name_plural = _('news')
Добавьте каждому полю имя, текст справки (если требуется) и
форму множественного числа. Перейдите в каталог news и проделайте те же действия по созданию, переводу и компиляции языковых файлов, что я описывал ранее. После всех операций у вас должно получиться что-то вроде изображенного на рис. 3 и 4.

[[Изображение:LXF107 90 2.png|frame|center|Рис. 3. Русифицированная главная страница админки…]]
[[Изображение:LXF107 90 3.png|frame|center|Рис. 4. ...и форма добавления новостей.]]

=== Кэширование ===
Наиболее слабыми звеньями работы сайта являются доступ к базе
данных и компилирование шаблонов, поэтому стоит сразу задуматься о кэшировании данных. Django прекрасно справляется этой
задачей и позволяет создавать и хранить кэш самыми различными
способами и в самых разных местах:
* В оперативной памяти. Такая возможность достигается с помощью программы Memcached, которая служит промежуточным звеном между данными в памяти и Django. Несомненно, этот способ является наибыстрейшим, однако ваш сервер должен обладать достаточным количеством памяти, чтобы хватило и для Django, и для кэша.
* В базе данных. В этом случае о скорости доступа к данным нельзя говорить однозначно, так как тут нужно учитывать настройки самой БД; однако если все сделано с умом, можно ожидать хороших результатов.
* В файловой системе. Самый простой вариант. Его мы и будем использовать.
Откроем файл settigns.py и объявим в нем переменную:
CACHE_BACKEND = 'file:///путь/до/кэша'
Слово file означает, что мы собираемся использовать файловую
систему (против memcached и db для оперативной памяти и СУБД,
соответственно), далее идут три слэша и путь до директории, в которой вы собираетесь хранить данные.

{{Врезка
|Заголовок=Уровнем ниже
|Содержание=Низкоуровневое кэширование позволяет хранить любые данные, от переменных и экземпляров классов до фрагментов
шаблонов и баз данных. Для работы с ним нужно импортировать в представление модуль cache:
from django.core.cache import cache
В большинстве случаев вам будет достаточно пользоваться тремя функциями – cache.set для создания кэша, cache.
get для извлечения данных, cache.delete для удаления кэша.
Рассмотрим их поподробнее:
* cache.set('name', 'value', 60) принимает три параметра: имя кэша, значение и время хранения.
* cache.get('name') – принимает только имя.
* cache.delete('name') – только имя.
|Ширина=300px}}
Django предоставляет высокоуровневые механизмы для генерации кэша и извлечения его из базы данных. Так, самым верхним
объектом является кэш всех страниц сайта. Однако если на странице
находятся динамические данные, которые индивидуальны для каждого пользователя, например, строка приветствия («Здравствуйте,
Имя»), то все посетители будут видеть приветствие для пользователя, который зашел на сайт самым первым. Если же таких элементов нет, это – самый быстрый способ создать кэш сайта. Чтобы
включить его, достаточно добавить строку 'django.middleware.cache.CacheMiddleware' в кортеж MIDDLEWARE_CLASSES в файле настроек. Она должна стоять самой первой в кортеже. На нашем сайте нет
приветствия, однако есть возможность смены языков, и после того
как кэш страницы создан для одного языка, он будет отображаться
и для другого.

Следующим глобальным объектом для кэширования является
представление. И опять, здесь мы сталкиваемся с теми же недостатками, что и при кэшировании всех страниц сайта, с единственным
отличием: мы сами вправе выбирать, какие страницы будут кэшироваться, а какие – нет. Вы можете импортировать в ваше представление декоратор cache_page:
from django.views.decorators.cache import cache_page
и применить его к какому-либо представлению, например:
@cache_page(60 * 15)
def last_news(request):
...
Декоратор принимает единственный параметр – время жизни
кэша в секундах.

Аналогично можно кэшировать и шаблоны. Откройте файл
news/templates/news/last_news.html и добавьте после {% extends
«index.html» %} строку:
{% load cache %}
далее, перед {% for news in last_news %} добавьте
{% cache 31536000 last_news LANGUAGE_CODE %}
а после {% endfor %}:
{% endcache %}
Сначала мы подключаем дополнительные тэги для кэширования,
затем вызываем тэг {% cache %} с тремя параметрами (вообще-то
достаточно двух). Первый – время жизни кэша в секундах (у нас
это целый год), второй – название, а третий – тоже название, но в
нашем случае это переменная, которая вычисляется динамически, а
следовательно, для разных языков у нас создается свой кэш. То же
самое можно сделать и для приветствия.

=== Сигналы ===
Кэширование позволяет сделать сайт очень быстрым, но как
быть, если вы определили время жизни кэша в три дня и добавили новость через два? Ведь пока кэш жив, система будет отображать именно его, и нашим посетителям придется ждать целый
день. С другой стороны, ставить слишком маленький промежуток
тоже нет смысла – тогда от системы кэширования не будет пользы. Предугадать невозможно, да и незачем. Оптимальный вариант – удалять кэш при наступлении какого-либо события (новость
добавлена, новость удалена и т.д.). Уведомлением о событии служит сигнал. Создадим внутри директории news файл signals.py
следующего содержания:
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
from django.core.cache import cache
from settings import LANGUAGES

def delete_last_news_cache():
for lang in LANGUAGES:
cache.delete('last_news:'+ lang[0])</source>
Обратите внимание на строку 6, где мы генерируем имя кэша.
Здесь учтено, что Django соединяет все, что было передано тэгу {%
cache %}, символом двоеточия. Поскольку мы не знаем, для каких
языков был создан кэш, то удаляем все возможные варианты – в
нашем случае их всего два.

Как же сделать, чтобы этот код выполнялся? Проще простого. Откроем файл news/models.py и добавим в начало следующие
строки:
from django.db.models import signals
from django.dispatch import dispatcher
from news.signals import delete_last_news_cache
а в конец:
dispatcher.connect(delete_last_news_cache,signal=signals.post_save,sender=News)
dispatcher.connect(delete_last_news_cache,signal=signals.post_delete,sender=News)
Теперь в системе зарегистрированы два сигнала от передатчика
(sender) News. Первый сигнал генерируется после сохранения объекта в базе данных, то есть при его создании или изменении, а второй – после удаления. В обоих случаях выполняется функция delete_last_news_cache, определенная выше. Вообще, для обращения к
базе данных в Django существует семь сигналов: pre_init, post_init,
pre_save, post_save, pre_delete, post_delete и post_syncdb, названия
которых говорят сами за себя.

=== И сверх этого ===
Кроме возможности создавать кэш ваших данных, Django поддерживает и другие способы оптимизации. Чтобы сделать ваш сайт еще,
быстрее нужно добавить в кортеж MIDDLEWARE_CLASSES в файле
settings.py следующие строки:
'django.middleware.http.ConditionalGetMiddleware',
'django.middleware.gzip.GZipMiddleware',
Первая из них включает поддержку условных GET-запросов
(использование ETag и Last-Modified в HTTP-заголовках), а вторая
отвечает за сжатие содержимого для браузеров, которые поддерживают такую возможность (а это все современные реализации).

LXF108:Django

2009-08-31T14:49:52Z

Shultais: Добавлена ссылка на сайт автора

{{Цикл/Django}}
== Финальные штрихи ==
: ''ЧАСТЬ 4 Уроки Django подходят к концу, наступает пора экзаменов – если не для вас, то для приложений уж точно. '''Никита Шультайс''' (http://shultais.ru) разберется с тестированием и пробежится по другим возможностям этого каркаса.''

Новостная лента готова – но оправдает ли она ожидания
пользователей? Ответ на этот вопрос может дать тестирование, лучше всего – в реальных условиях; но какие-то
основные вещи можно проверить еще на этапе разработки. Если вы
успели заглянуть в учебник [[LXF108:Rails|Rails]], то уже знаете о методологии TDD. Мы, однако, пойдем другим путем, и будем тестировать
приложение не до написания, а после.

Дело это – серьезное и сложное, так как нам нужно учитывать
взаимодействие с БД, компиляцию шаблонов, обработку GET- и
POST-запросов и прочие компоненты системы: сбой в любом из
них может вызвать нарушить работу всего сайта. К данной задаче
можно подойти с двух сторон:
* Тестирование в браузере. Речь идет о программах Twill (http://twill.idyll.org) и Selenium (http://selenium.openqa.org): они «запоминают» последовательность ваших действий для каждой страницы, а затем воспроизводят ее по запросу. Например, можно ввести в поля формы заведомо неверные данные, получить ожидаемую ошибку и повторять этот тест при каждом серьезном изменении в коде вашего приложения.
* Тестирование на сервере. И тут Django не оставляет нас на произвол судьбы, предлагая сразу два варианта: doctest (тестирование через документацию) и unittest (модульное тестирование), плюс специальный клиент для отправки GET- и POST-запросов.

Если вы давно программируете на Python, то вам, наверное,
будет ближе doctest, а мигрантам из мира Java скорее придется по
вкусу unittest. Никаких ограничений на их использование не накладывается: вы можете выбрать одну систему или применять обе сразу. Мы же остановимся на doctest.

=== Документируй это! ===
Строка документации в Python – это обычный текст, размещаемый
после определения функции или класса непосредственно в исходном
коде. Она же предоставляет содержимое для атрибута __doc__. Как
правило, ее помещают в тройные кавычки ("""), что позволяет вводить
сложные конструкции с переносами строк, отступами, теми же кавычками и... тестами. Этим мы и воспользуемся.

Тесты могут находится в файлах моделей (models.py) – для проверки последних – и в специальных файлах tests.py, расположенных
в директории приложения. К примеру, создайте файл news/tests.py
такого содержания:
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
# -*- coding: utf-8 -*-

"""
>>> from news.models import News
>>> from datetime import datetime
>>> news = News(title="Заголовок",description="Описание",pub_date=datetime.now(), text="Текст")
>>> news.save()
>>> news = News.objects.get(pk=1)
>>> print news.title.encode('utf-8')
Заголовок
"""
</source>
В строке 1 задается кодировка, а начиная с третьей идет сам
тест. Заметьте, что каждая строка начинается с трех знаков «больше» (>>>), как в интерактивном режиме работы Python. В строке 10
этих знаков нет, так как она содержит ожидаемый вывод команды
print со строки 9.

[[Изображение:LXF108 85 1.png|thumb|200px|Рис. 1. Тест пройден удачно!]]
Перед тем, как запустить тест, в settings.py нужно добавить
строку
TEST_DATABASE_CHARSET="UTF8"
чтобы кодировки файла и базы данных совпадали. Перед выполнением теста Django создаст специальную вспомогательную БД, поэтому
пользователь, указанный в settings.DATABASE_USER, должен иметь
соответствующие права. Для начала тестирования введите команду:
python manage.py test news
после выполнения которой вы увидите примерно то, что показано
на рис. 1.

Сообщения похожи на появляющиеся во время создания таблиц
при первой установке, но теперь все происходит в тестовой БД. В
конце отображается число выполненных тестов, их результаты и
уведомление об уничтожении тестовой базы. Мы проверяли наше
приложение (news), но, как вы помните, Django содержит несколько
собственных приложений и представлений (например, «админку») –
и они тоже снабжаются своими тестами. Чтобы выполнить их все,
нужно ввести команду:
python manage.py test
добавив предварительно в главный файл URL-карт следующие
строки:
<source lang="python">urlpatterns += patterns('django.contrib.auth.views',
url(r'^auth/password_reset/$','password_reset'),
)</source>
Здесь мы подключаем одно из встроенных представлений, предназначенное для восстановления пароля. Это необходимо, так как при
тестировании всего проекта происходит обращение по указанному URL,
и если представление не определено, тест будет провален. Кстати, вы
тоже можете попробовать password_reset в работе (рис. 2).
[[Изображение:LXF108 85 2.png|frame|center|Рис. 2. Забыли пароль? Это проблемы Django!]]

=== Имитатор Сети ===
Количество тестов уже достигло шести, но помимо создания и
извлечения объектов из базы, нам нужно проверить реакцию на
GET- и POST-запросы. Как вы знаете, для этих целей существует
специальный клиент: он эмулирует запрос и возвращает переменные, которые передаются в шаблон для данного URL. Добавьте в
файл tests.py после строки 10 следующий код:
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS" line start="11">
>>> from django.contrib.auth.models import User
>>> user = User.objects.create_user('django_guru', 'user@example.com', 'password')
>>> user.save()
>>> from django.test.client import Client
>>> c = Client()
>>> c.login(username='django_guru',password=“password”)
True
>>> response = c.get('/news/1/')
>>> response.status_code
200
>>> print response.context[0]['user'].username
django_guru
>>> response = c.post('/news/1/',{'username':“testuser”,'text':»»})
>>> response.status_code
200
>>> response = c.post('/news/1/',{'username':“testuser”,'text':»Comment text»})
>>> response.status_code
302
>>> from news.models import Comment
>>> comment = Comment.objects.get(news=news)
>>> print comment.text
Comment text</source>
Разберемся, что здесь происходит. В строках 11–13 мы создаем
нового пользователя (django_guru), а в 14–15 – тестовый клиент. В
строке 16 django_guru авторизуется, и отныне все действия в системе
будут совершаться от его имени. В строке 18 мы переходим на страницу нашей первой новости, передав средствами клиента GET-запрос.
Для проверки, что нам это удалось, мы изучаем код ответа сервера
(строка 19) – он должен равняться 200, или тест будет провален.
Затем (строки 21–22), чтением дополнительных данных ответа, мы
убеждаемся, что запрос сделал зарегистрированный пользователь
django_guru. Теперь самое время оставить комментарий – не зря же
мы авторизовались? В строке 23 генерируется POST-запрос (второй
аргумент метода post() – словарь отсылаемых на сервер данных).
Обратите внимание, что значение ключа text оставлено пустым, а
значит, комментарий не добавится, однако сервер по-прежнему должен возвращать код 200 (строка 25). А вот в строке 26 мы передаем
все необходимые данные, и так как после создания комментария нас
перенаправляют на страницу новости, код ответа должен быть равен
302 (Требуемый URL перемещен). В строках 29–32 проверяется, что
комментарий был действительно добавлен: мы сравниваем его текст
с исходным значением. Уфф... тест пройден.

=== Действительно простая синдикация ===
Какой новостной сайт без ленты? RSS и/или Atom есть везде – будут
и у нас, а Django нам в этом поможет. Откройте главный файл URL-карт и добавьте в его конец следующие строки:
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
from feeds import LatestNews

feeds = {
'latest': LatestNews,
}
urlpatterns += patterns('',
(r'^feeds/(?P<url>.*)/$', 'django.contrib.syndication.views.feed',
{'feed_dict': feeds}),
)
</source>
Далее нужно приготовить ленту LatestNews, которую мы импортируем в строке 1. Создайте в корне проекта каталог feeds с файлом
__init__.py следующего содержания:
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
# -*- coding: utf-8 -*-

from django.contrib.syndication.feeds import Feed
from news.models import News
from django.contrib.syndication.feeds import FeedDoesNotExist

class LatestNews(Feed):
title = "Последние новости нашего сайта"
description = "Последние события на сайте mysite.com"
link = "http://127.0.0.1:8000/news/"

def items(self):
return News.objects.order_by("-pub_date")[:5]

def item_link(self, obj):
from django.core.urlresolvers import reverse
return 'http://127.0.0.1:8000%s' % reverse('news.news_detail',kwargs={"news_id":obj.pk})
</source>
[[Изображение:LXF108 86 1.png|thumb|250px|Рис. 3. Firefox предлагает подписаться на обновления нашего новостного сайта – теперь держитесь!]]
Поля title, description и link класса LatestNews являются обязательными и отвечают за одноименные элементы RSS. Метод items()
передает в ленту требуемые объекты, а item_link() отвечает за ссылку
на сайт. Теперь создайте каталог feeds в media/templates и добавьте
в него два файла, latest_description.html и latest_title.html: они будут
отвечать за вид новостной ленты. В lates_description.html напишите:
<nowiki>{{ obj.description }}</nowiki>
а в latest_title.html:
<nowiki>[{{ obj.pub_date|date:"d.m.Y" }}] {{ obj.title }}</nowiki>
Объект obj представляет собой запись из выборки, которую мы
возвращаем в строке 13 файла feeds/__init__.py. Пройдя по адресу
http://127.0.0.1:8000/feeds/latest/, мы увидим предложение Firefox
сохранить ленту новостей. Пользователи KDE, вероятно, предпочтут
Akregator – с ним тоже нет никаких проблем (рис. 3, 4)

=== Общие представления ===
Чтобы облегчить жизнь web-разработчика, Django включил большое
число представлений для решения стандартных задач. Так, добавив
в главный файл URL-карт следующий код:
<source lang="python">
from django.views.generic.list_detail import object_list
from news.models import News
urlpatterns += patterns('',
('^lastnews/$', object_list, {
'queryset': News.objects.all().order_by('-pub_date')[:10],
'template_name':'news/last_news.html',
'template_object_name':'last_news'})
)</source>
а также заменив в файле news/templates/news/last_news.html
{% for news in last_news %}
на
{% for news in last_news_list %}
мы сможем просматривать последние новости по адресу
http://127.0.0.1:8000/lastnews/, не вызывая представление news.last_news. Чтобы сделать доступными оба варианта, нужно найти в представлении news.last_news строку
"last_news":news,
и заменить ее на
"last_news_list":news,
Как вы уже догадались, общее представление object_list предназначено для работы со списком объектов. Еще есть представления для
вывода объектов в зависимости от даты (django.views.generic.date_based.*), что позволяет очень просто создавать архивы записей:
* archive_index – вывод последних объектов, добавленных в базу данных;
* archive_{year,month,week,day,today} – вывод всех объектов за определенный год, месяц, неделю, день или за сегодня;
* object_detail – вывод одного объекта за определенный день.
Доступны общие представления для создания, обновления и
удаления объектов. Все они работают немного быстрее, чем созданные вручную, но позволяют решать лишь самые элементарные задачи. Если данные в вашем приложении выбираются из нескольких
таблиц и это сопровождается расчетами, то общие представления
не помогут – на то они и общие.

=== Добавляем переменные на лету ===
В глубинах Django скрываются глобальные контекстные процессоры, основная задача которых – снабжать шаблоны переменными
и объектами. Узнать, какие из них подключены, можно в кортеже
TEMPLATE_CONTEXT_PROCESSORS в файле settings.py. Например, у
нас сейчас работают следующие процессоры:
* auth – информация о пользователе: объект user, его права доступа и сообщения, которые были ему отправлены;
* i18n – сведения о текущем языке сайта и клиента;
* request – данные о запросе.
Кроме них, существует еще процессор debug, передающий в
шаблон данные о выполненных SQL-запросах, плюс мы можем
написать свой собственный! Для этого создадим в корне нашего
проекта каталог processors и добавим в него два файла: __init__.py
и context_processors.py. Последний должен содержать такой код:
<source lang="python">
import settings
def site_settings(request):
return {'SETTINGS': settings}</source>
Чтобы подключить процессор, просто перечислите его в кортеже
TEMPLATE_CONTEXT_PROCESSORS. Проверим работоспособность:
добавим в шаблон news.html следующее:
<nowiki>{{ SETTINGS.TIME_ZONE }}</nowiki>
Конечно, TIME_ZONE можно заменить на любую другую переменную, определенную в settings.py.

=== Сам себе фильтр ===
С фильтрами мы познакомились еще в [[LXF105:Django|LXF105]], однако часто возникают ситуации, когда поставляемых с Django вариантов недостаточно. Чтобы написать свой собственный фильтр, создайте в корне
проекта каталог templatetags/ и добавьте в него файлы __init__.py
и filters.py. В filters.py напишите:
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
from django import template

register = template.Library()

@register.filter
def exp(value, arg):
if value.isdigit() and arg.isdigit():
return int(value)**int(arg)
else:
return '<span style=“color:red”>Error</span>'
exp.is_safe = True</source >
Мы создали фильтр exp, который получает значение и показатель степени и возводит одно в другое; если аргументы не являются числами, генерируется ошибка. В строке 5 мы регистрируем
фильтр в системе с помощью декоратора. Строка 11 указывает,
что exp может возвращать HTML-код. Поскольку (в целях безопасности) он автоматически экранируется (< и > заменяются на &lt; и
&gt; и т.д.), то, желая видеть чистый HTML, мы должны запретить
такое поведение вручную. Следующим шагом является подгрузка
библиотеки фильтров в шаблон, для чего нужно добавить в него
следующую строку:
{% load filters %}
Вообще-то Django ищет созданные библиотеки шаблонов в корне приложения, поэтому наш фильтр пока не будет доступен. Это
не очень удобно, особенно если мы хотим использовать один и тот
же фильтр во многих приложениях. Решение – создать для проекта
единую библиотеку, а в приложения помещать лишь символьные
ссылки на нее.
<source lang="bash">ln -s /var/www/myproject/templatetags/ /var/www/myproject/news/</source>
Теперь проверим работу фильтра, добавив в какой-нибудь шаблон
строку.
<nowiki>{{ "4"|exp:"4" }}</nowiki>
Во время компиляции она будет заменена на 256. Если же мы
напишем
<nowiki>{{ "a"|exp:"4" }}</nowiki>
то увидим слово «Error», выделенное красным цветом.
Кстати, если бы мы не указали в строке 11 фильтра exp.is_safe= True, можно было бы просто применить фильтр safe прямо в
шаблоне:
<nowiki>{{ "a"|exp:"4"|safe }}</nowiki>
После регистрации фильтра в системе, информация о нем становится доступной по адресу http://127.0.0.1:8000/admin/doc/filters/
(рис. 4)
[[Изображение:LXF108 87 1.png|frame|center|Рис. 4. Система любезно подскажет, как использовать созданный вами фильтр.]]

=== Компоненты ===
Если нам надо выполнить какие-либо действия до или после того,
как будет вызвано представление, либо в случае ошибки, можно создать свой компонент (middleware) или воспользоваться
поставляемым с Django. Мы уже делали это, когда изучали кэширование ([[LXF107:Django|LXF107]]). Напомню, что в файле settings.py есть кортеж
MIDDLEWARE_CLASSES, который перечисляет компоненты, задействованные в проекте. У нас это:
* django.middleware.common.CommonMiddleware Решает общие задачи: нормализует URL (добавляет префикс www и завершающий /), запрещает доступ к сайту определенным роботам, взаимодействует с Etag.
* django.contrib.sessions.middleware.SessionMiddleware Это сессии.
* django.contrib.auth.middleware.AuthenticationMiddleware А это – авторизация.
* django.middleware.doc.XViewMiddleware Используется для автоматического документирования Django.
* django.middleware.locale.LocaleMiddleware Интернационализация.
Помимо перечисленных выше, в Django доступны следующие
компоненты (django.middleware.*):
* gzip.GZipMiddleware Сжатие отправляемой страницы для экономии трафика.
* http.ConditionalGetMiddleware Поддержка условных GET-запросов для работы с Last-Modified и Etag.
* http.SetRemoteAddrFromForwardedFor Обратное проксирование.
* cache.CacheMiddleware Тот самый кэш, с которым мы сталкивались на прошлом уроке.
* transaction.TransactionMiddleware Компонент для включения в SQL-запросы транзакционных конструкций: COMMIT, ROLLBACK.
Заметьте, что не все базы данных поддерживают транзакции.

И, наконец, django.contrib.csrf.middleware.CsrfMiddleware, защищающее от CSRF-атак.

По сложившейся уже традиции, рассмотрим, как написать свой
собственный компонент. С точки зрения программиста, это просто
класс Python, имеющий ряд методов, вызываемых Django в определенные моменты времени. Первым из них является конструктор
__init__(self), регистрирующий компонент в системе. Дальше следуют методы, определяющие порядок выполнения кода:
* process_request() – запускается после того, как поступил запрос,но перед тем как Django начнет искать запрашиваемый адрес в URL-картах;
* process_view() – отрабатывает, когда конкретное представление уже определено, но еще не запущено;
* process_response() – выполняется после представления.
Используется для сжатия сгенерированного HTML.
process_exception() – вызывается, если что-то пошло не так или
было возбуждено необработанное исключение.

Вот, в сущности, и все. Впрочем, нет – взгляните на врезку И
прочая, прочая, прочая, почитайте документацию или свободную
книгу о Django – Django Book (http://www.djangobook.com); если же вам
больше по душе русский, советую заглянуть на http://cargo.caml.ru/djangobook. Наконец, примените полученные знания на практике – и дайте нам знать, если у вас получится что-то действительно стоящее!

{{Врезка|center|
|Заголовок=И прочая, прочая, прочая...
|Содержание=За четыре урока мы успели рассмотреть почти все возможности
Django, но кое-что осталось неохваченным...
*; Электронная почта
Django предлагает высокоуровневый API для отправки письма в
одно действие:
<source lang="python">from django.core.mail import send_mail
send_mail('Тема', 'сообщение.', 'from@example.com', ['to@example.com'], fail_silently=False)</source>
Кроме того, есть функции массовой рассылки сообщений, оповещения администраторов и менеджеров сайта, а также работы с
различным содержимым (HTML, текст, графика и т.п.)
*; CSV и PDF
Django позволяет легко формировать файлы с данными, разделенными запятыми (CSV), а также PDF-документы, используя
библиотеку ReportLab (http://www.reportlab.org/rl_toolkit.html).
*; Постраничный вывод
Когда количество объектов настолько велико, что одной страницы становится мало, на помощь приходит специальный класс
Paginator, который помогает организовать постраничный вывод:
<source lang="python">>>> from django.core.paginator import Paginator
>>> objects = ['django', 'python', 'mysql', 'apache']
>>> p = Paginator(objects, 2)
>>> page1 = p.page(1)
>>> page1.object_list
['django', 'python']</source>
Поскольку большинство наших объектов хранятся в базе данных,
Django также предлагает класс QuerySetPaginator, который принимает не список, а множество объектов из СУБД.
*; Карты сайта
Хотите, чтобы ваш сайт правильно индексировался поисковыми
машинами? Необходимо создать его карту! Django поможет и
здесь, а функция django.contrib.sitemaps.ping_google «заставит»
Google обновить индексы для вашего сайта.
*; Управление несколькими сайтами
Одной из задач, с которой успешно справляется Django, является
управление несколькими схожими по тематике сайтами из одной
инсталляции. Проект первоначально разрабатывался как платформа для новостных порталов, и одна новость могла появиться
сразу на нескольких ресурсах.
*; В помощь дизайнерам
Подгрузив к шаблонам модуль помощи дизайнерам:
{% load webdesign %}
вы получите в свое распоряжение тэг {% lorem %}, с помощью
которого можно выводить известную латинскую фразу «lorem
ipsum ...» для заполнения шаблонов «рыбой».
*; И более того
Django содержит много других «вкусностей», которые очень
хорошо описаны в прилагающейся документации на английском
языке.
|Ширина=}}