This tutorial begins where Tutorial 3 left off. We’re\ncontinuing the Web-poll application and will focus on simple form processing and\ncutting down our code.
\nLet’s update our poll detail template (“polls/detail.html”) from the last\ntutorial, so that the template contains an HTML <form> element:
polls/templates/polls/detail.html<h1>{{ question.question_text }}</h1>\n\n{% if error_message %}<p><strong>{{ error_message }}</strong></p>{% endif %}\n\n<form action="{% url 'polls:vote' question.id %}" method="post">\n{% csrf_token %}\n{% for choice in question.choice_set.all %}\n <input type="radio" name="choice" id="choice{{ forloop.counter }}" value="{{ choice.id }}" />\n <label for="choice{{ forloop.counter }}">{{ choice.choice_text }}</label><br />\n{% endfor %}\n<input type="submit" value="Vote" />\n</form>\nA quick rundown:
\nThe above template displays a radio button for each question choice. The\nvalue of each radio button is the associated question choice’s ID. The\nname of each radio button is "choice". That means, when somebody\nselects one of the radio buttons and submits the form, it’ll send the\nPOST data choice=# where # is the ID of the selected choice. This is the\nbasic concept of HTML forms.
We set the form’s action to {% url 'polls:vote' question.id %}, and we\nset method="post". Using method="post" (as opposed to\nmethod="get") is very important, because the act of submitting this\nform will alter data server-side. Whenever you create a form that alters\ndata server-side, use method="post". This tip isn’t specific to\nDjango; it’s just good Web development practice.
forloop.counter indicates how many times the for tag has gone\nthrough its loop
Since we’re creating a POST form (which can have the effect of modifying\ndata), we need to worry about Cross Site Request Forgeries.\nThankfully, you don’t have to worry too hard, because Django comes with\na very easy-to-use system for protecting against it. In short, all POST\nforms that are targeted at internal URLs should use the\n{% csrf_token %} template tag.
Now, let’s create a Django view that handles the submitted data and does\nsomething with it. Remember, in Tutorial 3, we\ncreated a URLconf for the polls application that includes this line:
\npolls/urls.pyurl(r'^(?P<question_id>[0-9]+)/vote/$', views.vote, name='vote'),\nWe also created a dummy implementation of the vote() function. Let’s\ncreate a real version. Add the following to polls/views.py:
polls/views.pyfrom django.shortcuts import get_object_or_404, render\nfrom django.http import HttpResponseRedirect, HttpResponse\nfrom django.core.urlresolvers import reverse\n\nfrom .models import Choice, Question\n# ...\ndef vote(request, question_id):\n question = get_object_or_404(Question, pk=question_id)\n try:\n selected_choice = question.choice_set.get(pk=request.POST['choice'])\n except (KeyError, Choice.DoesNotExist):\n # Redisplay the question voting form.\n return render(request, 'polls/detail.html', {\n 'question': question,\n 'error_message': "You didn't select a choice.",\n })\n else:\n selected_choice.votes += 1\n selected_choice.save()\n # Always return an HttpResponseRedirect after successfully dealing\n # with POST data. This prevents data from being posted twice if a\n # user hits the Back button.\n return HttpResponseRedirect(reverse('polls:results', args=(question.id,)))\nThis code includes a few things we haven’t covered yet in this tutorial:
\nrequest.POST is a dictionary-like\nobject that lets you access submitted data by key name. In this case,\nrequest.POST['choice'] returns the ID of the selected choice, as a\nstring. request.POST values are\nalways strings.
Note that Django also provides request.GET for accessing GET data in the same way –\nbut we’re explicitly using request.POST in our code, to ensure that data is only\naltered via a POST call.
request.POST['choice'] will raise KeyError if\nchoice wasn’t provided in POST data. The above code checks for\nKeyError and redisplays the question form with an error\nmessage if choice isn’t given.
After incrementing the choice count, the code returns an\nHttpResponseRedirect rather than a normal\nHttpResponse.\nHttpResponseRedirect takes a single argument: the\nURL to which the user will be redirected (see the following point for how\nwe construct the URL in this case).
As the Python comment above points out, you should always return an\nHttpResponseRedirect after successfully dealing with\nPOST data. This tip isn’t specific to Django; it’s just good Web\ndevelopment practice.
We are using the reverse() function in the\nHttpResponseRedirect constructor in this example.\nThis function helps avoid having to hardcode a URL in the view function.\nIt is given the name of the view that we want to pass control to and the\nvariable portion of the URL pattern that points to that view. In this\ncase, using the URLconf we set up in Tutorial 3,\nthis reverse() call will return a string like
'/polls/3/results/'\nwhere the 3 is the value of question.id. This redirected URL will\nthen call the 'results' view to display the final page.
As mentioned in Tutorial 3, request is an\nHttpRequest object. For more on\nHttpRequest objects, see the request and\nresponse documentation.
After somebody votes in a question, the vote() view redirects to the results\npage for the question. Let’s write that view:
polls/views.pyfrom django.shortcuts import get_object_or_404, render\n\n\ndef results(request, question_id):\n question = get_object_or_404(Question, pk=question_id)\n return render(request, 'polls/results.html', {'question': question})\nThis is almost exactly the same as the detail() view from Tutorial 3. The only difference is the template name. We’ll fix this\nredundancy later.
Now, create a polls/results.html template:
polls/templates/polls/results.html<h1>{{ question.question_text }}</h1>\n\n<ul>\n{% for choice in question.choice_set.all %}\n <li>{{ choice.choice_text }} -- {{ choice.votes }} vote{{ choice.votes|pluralize }}</li>\n{% endfor %}\n</ul>\n\n<a href="{% url 'polls:detail' question.id %}">Vote again?</a>\nNow, go to /polls/1/ in your browser and vote in the question. You should see a\nresults page that gets updated each time you vote. If you submit the form\nwithout having chosen a choice, you should see the error message.
The detail() (from Tutorial 3) and results()\nviews are very simple – and, as mentioned above, redundant. The index()\nview, which displays a list of polls, is similar.
These views represent a common case of basic Web development: getting data from\nthe database according to a parameter passed in the URL, loading a template and\nreturning the rendered template. Because this is so common, Django provides a\nshortcut, called the “generic views” system.
\nGeneric views abstract common patterns to the point where you don’t even need\nto write Python code to write an app.
\nLet’s convert our poll app to use the generic views system, so we can delete a\nbunch of our own code. We’ll just have to take a few steps to make the\nconversion. We will:
\nConvert the URLconf.
Delete some of the old, unneeded views.
Introduce new views based on Django’s generic views.
Read on for details.
\n\nFirst, open the polls/urls.py URLconf and change it like so:
polls/urls.pyfrom django.conf.urls import url\n\nfrom . import views\n\napp_name = 'polls'\nurlpatterns = [\n url(r'^$', views.IndexView.as_view(), name='index'),\n url(r'^(?P<pk>[0-9]+)/$', views.DetailView.as_view(), name='detail'),\n url(r'^(?P<pk>[0-9]+)/results/$', views.ResultsView.as_view(), name='results'),\n url(r'^(?P<question_id>[0-9]+)/vote/$', views.vote, name='vote'),\n]\nNote that the name of the matched pattern in the regexes of the second and third\npatterns has changed from <question_id> to <pk>.
Next, we’re going to remove our old index, detail, and results\nviews and use Django’s generic views instead. To do so, open the\npolls/views.py file and change it like so:
polls/views.pyfrom django.shortcuts import get_object_or_404, render\nfrom django.http import HttpResponseRedirect\nfrom django.core.urlresolvers import reverse\nfrom django.views import generic\n\nfrom .models import Choice, Question\n\n\nclass IndexView(generic.ListView):\n template_name = 'polls/index.html'\n context_object_name = 'latest_question_list'\n\n def get_queryset(self):\n """Return the last five published questions."""\n return Question.objects.order_by('-pub_date')[:5]\n\n\nclass DetailView(generic.DetailView):\n model = Question\n template_name = 'polls/detail.html'\n\n\nclass ResultsView(generic.DetailView):\n model = Question\n template_name = 'polls/results.html'\n\n\ndef vote(request, question_id):\n ... # same as above, no changes needed.\nWe’re using two generic views here:\nListView and\nDetailView. Respectively, those\ntwo views abstract the concepts of “display a list of objects” and\n“display a detail page for a particular type of object.”
Each generic view needs to know what model it will be acting\nupon. This is provided using the model attribute.
The DetailView generic view\nexpects the primary key value captured from the URL to be called\n"pk", so we’ve changed question_id to pk for the generic\nviews.
By default, the DetailView generic\nview uses a template called <app name>/<model name>_detail.html.\nIn our case, it would use the template "polls/question_detail.html". The\ntemplate_name attribute is used to tell Django to use a specific\ntemplate name instead of the autogenerated default template name. We\nalso specify the template_name for the results list view –\nthis ensures that the results view and the detail view have a\ndifferent appearance when rendered, even though they’re both a\nDetailView behind the scenes.
Similarly, the ListView generic\nview uses a default template called <app name>/<model\nname>_list.html; we use template_name to tell\nListView to use our existing\n"polls/index.html" template.
In previous parts of the tutorial, the templates have been provided\nwith a context that contains the question and latest_question_list\ncontext variables. For DetailView the question variable is provided\nautomatically – since we’re using a Django model (Question), Django\nis able to determine an appropriate name for the context variable.\nHowever, for ListView, the automatically generated context variable is\nquestion_list. To override this we provide the context_object_name\nattribute, specifying that we want to use latest_question_list instead.\nAs an alternative approach, you could change your templates to match\nthe new default context variables – but it’s a lot easier to just\ntell Django to use the variable you want.
Run the server, and use your new polling app based on generic views.
\nFor full details on generic views, see the generic views documentation.
\nWhen you’re comfortable with forms and generic views, read part 5 of this\ntutorial to learn about testing our polls app.
\n