Продолжаем начатое в третьей части учебника. Мы продолжим разрабатывать приложение для голосования и сосредоточимся на обработке форм и упрощении нашего кода.
Отредактируем шаблон страницы опроса (“polls/detail.html”) из предыдущего раздела учебника, и добавим HTML элемент <form>:
<h1>{{ question.question_text }}</h1>
{% if error_message %}<p><strong>{{ error_message }}</strong></p>{% endif %}
<form action="{% url 'polls:vote' question.id %}" method="post">
{% csrf_token %}
{% for choice in question.choice_set.all %}
<input type="radio" name="choice" id="choice{{ forloop.counter }}" value="{{ choice.id }}" />
<label for="choice{{ forloop.counter }}">{{ choice.choice_text }}</label><br />
{% endfor %}
<input type="submit" value="Vote" />
</form>
Краткий обзор:
Данный шаблон отображает radio-поле для каждого варианта ответа вопроса. value поля содержит ID ответа. name каждого поля равно "choice". Это означает, что при выборе поля и отправке формы, будет отправлены POST данные choice=#, где # равно ID выбранного ответа. Это основной принцип работы HTML форм.
Значение action формы равно {% url 'polls:vote' question.id %}, еще добавлено method="post". Использование method="post" (вместо method="get") очень важно, так как отправка формы изменяет данные. Для форм изменяющих данные используйте method="post". Этот совет не относится к Django, это хорошая практика для Web-приложений.
forloop.counter содержит номер итерации цикла тега for
Так как мы создаем POST форму (которая может привести к изменениям данных), нам следует побеспокоится о Cross Site Request Forgeries. Благодаря Django это очень просто. В общем, все POST формы, которые отправляются на внутренний URL, должны использовать тег {% csrf_token %}.
Теперь создадим представление Django, которое принимает данные отправленные формой и обрабатывает их. Вспомним, в Части 3 мы создали URLconf который содержит следующую строку:
url(r'^(?P<question_id>[0-9]+)/vote/$', views.vote, name='vote'),
Мы также создали функцию-“заглушку” vote(). Давайте создадим настоящую функцию представления. Добавьте следующее в polls/views.py:
from django.shortcuts import get_object_or_404, render
from django.http import HttpResponseRedirect, HttpResponse
from django.core.urlresolvers import reverse
from .models import Choice, Question
# ...
def vote(request, question_id):
question = get_object_or_404(Question, pk=question_id)
try:
selected_choice = question.choice_set.get(pk=request.POST['choice'])
except (KeyError, Choice.DoesNotExist):
# Redisplay the question voting form.
return render(request, 'polls/detail.html', {
'question': question,
'error_message': "You didn't select a choice.",
})
else:
selected_choice.votes += 1
selected_choice.save()
# Always return an HttpResponseRedirect after successfully dealing
# with POST data. This prevents data from being posted twice if a
# user hits the Back button.
return HttpResponseRedirect(reverse('polls:results', args=(question.id,)))
Этот код содержит вещи, которые еще не объяснялись в учебнике:
request.POST – это объект с интерфейсом словаря, который позволяет получить отправленные данные через название ключа. В нашем случае request.POST['choice'] вернет ID выбранного варианта ответа в виде строки. request.POST всегда содержит строки.
Заметим что Django также предоставляет request.GET для аналогичного доступа к GET данным – но мы используем request.POST, чтобы быть уверенным, что данные передаются только при POST запросе.
request.POST['choice'] вызовет исключение KeyError, если choice не находится в POST. Код обрабатывает исключение KeyError и показывает страницу опроса с ошибкой, если не был выбран вариант ответа.
После увеличения счетчика ответов представление возвращает HttpResponseRedirect вместо HttpResponse. HttpResponseRedirect принимает один аргумент: URL, на который необходимо перенаправить пользователя (обратите внимание, как мы создаем URL).
После успешной обработки POST запроса, вы должны возвращать HttpResponseRedirect. Это не относится конкретно к Django, это просто хорошая практика при разработке Web-приложений.
Мы используем функцию reverse() при создании HttpResponseRedirect. Это функция помогает избегать “хардкодинга” URL-ов в коде. Она принимает название URL-шаблона и необходимые аргументы для создания URL-а. В этом примере используется конфигурация URL-ов из Части 3 и reverse() вернет:
'/polls/3/results/'
... где 3 значение question.id. При запросе к этому URL-у вызовется представление 'results' для отображения результатов опроса.
Как упоминалось в Части 3, request является экземпляром HttpRequest. Подробности о классе HttpRequest смотрите в разделе об объектах запроса и ответа.
После ответа на опрос, представление vote() перенаправит пользователя на страницу с результатами. Давайте создадим представление для этой страницы:
from django.shortcuts import get_object_or_404, render
def results(request, question_id):
question = get_object_or_404(Question, pk=question_id)
return render(request, 'polls/results.html', {'question': question})
Это представление аналогично представлению detail() из Части 3. Единственная разница - используемый шаблон. Повторение кода мы исправим позже.
Теперь создадим шаблон polls/results.html:
<h1>{{ question.question_text }}</h1>
<ul>
{% for choice in question.choice_set.all %}
<li>{{ choice.choice_text }} -- {{ choice.votes }} vote{{ choice.votes|pluralize }}</li>
{% endfor %}
</ul>
<a href="{% url 'polls:detail' question.id %}">Vote again?</a>
Теперь откройте страницу /polls/1/ в браузере и ответьте на опрос. Вы должны увидеть страницу с результатами, которые обновляются после каждого ответа на опрос. Если вы отправите форму, не ответив на вопрос, вы должны увидеть сообщение об ошибке.
Примечание
У кода представления vote() есть небольшие проблемы. Он сначала получает объект selected_choice из базы данных, затем рассчитывает новое значение votes, и сохраняет обратно в базу данных. Если два пользователя проголосуют в один момент, код может сработать неправильно: одно и то же значение, скажем 42, будет получено для votes. Затем для обоих пользователей получится и сохранится значение 43, хотя должно быть 44.
Это называется состояние гонки. Подробнее можете прочитать в разделе о Avoiding race conditions using F().
Представления detail() (из Части 3) и results() до глупости просты – и, как упоминалось выше, избыточны. Представление index(), которое показывает список опросов, также довольно стандартное.
Эти представления выполняют стандартные операции Веб-приложений: получение данных из базы данных в соответствии с параметрами из URL, загрузка шаблона и возвращение результата выполнения шаблона. Для таких стандартных операций Django предоставляет набор “общих представлений(generic views)”.
Общие представления позволяют создавать приложения практически не написав ни строчки кода Python.
Давайте используем их в нашем приложении. Необходимо выполнить следующие действия:
Изменить URLconf.
Удалить старые и ненужные представления.
Создать новые представления из встроенных в Django общих представлений.
Подробности читайте далее.
Зачем мы переписываем код?
Скорее всего, вы будете использовать общие представления с самого начала без необходимости рефакторить проект. Этот учебник специально описывает создание представлений, чтобы описать основные концепции.
Вы должны знать основы математики для использования калькулятора.
Первым делом откройте polls/urls.py и измените его следующим образом:
from django.conf.urls import url
from . import views
urlpatterns = [
url(r'^$', views.IndexView.as_view(), name='index'),
url(r'^(?P<pk>[0-9]+)/$', views.DetailView.as_view(), name='detail'),
url(r'^(?P<pk>[0-9]+)/results/$', views.ResultsView.as_view(), name='results'),
url(r'^(?P<question_id>[0-9]+)/vote/$', views.vote, name='vote'),
]
Обратите внимание, мы поменяли <question_id> на <pk> во втором и третьем URL-ах.
Теперь мы собираемся удалить старые представления index, detail и results и воспользуемся встроенными в Django общими представлениями. Для этого измените файл polls/views.py:
from django.shortcuts import get_object_or_404, render
from django.http import HttpResponseRedirect
from django.core.urlresolvers import reverse
from django.views import generic
from .models import Choice, Question
class IndexView(generic.ListView):
template_name = 'polls/index.html'
context_object_name = 'latest_question_list'
def get_queryset(self):
"""Return the last five published questions."""
return Question.objects.order_by('-pub_date')[:5]
class DetailView(generic.DetailView):
model = Question
template_name = 'polls/detail.html'
class ResultsView(generic.DetailView):
model = Question
template_name = 'polls/results.html'
def vote(request, question_id):
... # same as above
Мы используем здесь два общих представления: ListView и DetailView. Эти два типа представлений отображают две концепции: “отображение списка объектов” и “отображение подробностей о конкретном объекте”.
Каждое общее представление должно знать с какой моделью работать. Ее можно указать с помощью атрибута model.
Представление DetailView принимает значение первичного ключа из URL с названием "pk", поэтому мы изменили название параметра с question_id на pk.
По умолчанию представление DetailView использует шаблон <app name>/<model name>_detail.html. В нашем случае будет использоваться "polls/question_detail.html". Атрибут template_name позволяет указать Django какой шаблон использовать. Мы указали template_name также для представления results, чтобы страница результата и подробностей использовали разные шаблоны, несмотря на то, что они используют представление DetailView.
Аналогично ListView использует шаблон <app name>/<model name>_list.html, мы использовали template_name, чтобы определить другой шаблон - "polls/index.html".
В предыдущей части учебника в шаблоне использовался контекст с переменными question и latest_question_list. Для DetailView переменная question добавляется автоматически – так как мы используем модель Question, Django автоматически генерирует подходящее название для переменной контекста. Для ListView переменная будет называться question_list. Чтобы переопределить это название, мы использовали атрибут context_object_name указав latest_question_list. Как вариант, вы можете изменить шаблон и использовать question_list, но проще указать Django какое название переменной контекста использовать.
Запустите сервер и протестируйте наше приложение.
Подробности об общих представлениях смотрите в соответствующем разделе.
Когда вы освоите формы и общие представления, переходите к пятой части учебника, чтобы узнать о тестировании нашего приложения.
Jun 05, 2017