Write a simple form
Let’s update our poll detail template (“polls/detail.html”) from the last tutorial, so that the template contains an HTMLelement:
{{ poll.question }}
{% if error_message %}{{ error_message }}{% endif %}
action="/polls/{{ poll.id }}/vote/" method="post">
{% csrf_token %}
{% for choice in poll.choice_set.all %}
type="radio" name="choice" id="choice{{ forloop.counter }}" value="{{ choice.id }}" />
/>
{% endfor %}
type="submit" value="Vote" />
A quick rundown:
- The above template displays a radio button for each poll choice. The value of each radio button is the associated poll choice's ID. The name of each radio button is "choice". That means, when somebody selects one of the radio buttons and submits the form, it'll send the POST data choice=3. This is HTML Forms 101.
- We set the form's action to /polls/{{ poll.id }}/vote/, and we set method="post". Using method="post" (as opposed to method="get") is very important, because the act of submitting this form will alter data server-side. Whenever you create a form that alters data server-side, use method="post". This tip isn't specific to Django; it's just good Web development practice.
- forloop.counter indicates how many times the for tag has gone through its loop
- Since we're creating a POST form (which can have the effect of modifying data), we need to worry about Cross Site Request Forgeries. Thankfully, you don't have to worry too hard, because Django comes with a very easy-to-use system for protecting against it. In short, all POST forms that are targeted at internal URLs should use the {% csrf_token %} template tag.
from django.template import RequestContext
# ...
def detail(request, poll_id):
p = get_object_or_404(Poll, pk=poll_id)
return render_to_response('polls/detail.html', {'poll': p},
context_instance=RequestContext(request))Now, let's create a Django view that handles the submitted data and does something with it. Remember, in Tutorial 3, we created a URLconf for the polls application that includes this line:
(r'^(?P\d+)/vote/$' , 'vote'),from django.shortcuts import get_object_or_404, render_to_response
from django.http import HttpResponseRedirect, HttpResponse
from django.core.urlresolvers import reverse
from django.template import RequestContext
from mysite.polls.models import Choice, Poll
# ...
def vote(request, poll_id):
p = get_object_or_404(Poll, pk=poll_id)
try:
selected_choice = p.choice_set.get(pk=request.POST['choice'])
except (KeyError, Choice.DoesNotExist):
# Redisplay the poll voting form.
return render_to_response('polls/detail.html', {
'poll': p,
'error_message': "You didn't select a choice.",
}, context_instance=RequestContext(request))
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('mysite.polls.views.results', args=(p.id,)))
request.POST is a dictionary-like object that lets you access submitted data by key name. In this case, request.POST['choice'] returns the ID of the selected choice, as a string. request.POST values are always strings.Note that Django also provides request.GET for accessing GET data in the same way -- but we're explicitly using request.POST in our code, to ensure that data is only altered via a POST call.
request.POST['choice'] will raise KeyError if choice wasn't provided in POST data. The above code checks for KeyError and redisplays the poll form with an error message if choice isn't given.
After incrementing the choice count, the code returns an HttpResponseRedirect rather than a normal HttpResponse. HttpResponseRedirect takes a single argument: the URL to which the user will be redirected (see the following point for how we construct the URL in this case).As the Python comment above points out, you should always return an HttpResponseRedirect after successfully dealing with POST data. This tip isn't specific to Django; it's just good Web development practice.
We are using the reverse() function in the HttpResponseRedirect constructor in this example. This function helps avoid having to hardcode a URL in the view function. It is given the name of the view that we want to pass control to and the variable portion of the URL pattern that points to that view. In this case, using the URLconf we set up in Tutorial 3, this reverse() call will return a string like... where the 3 is the value of p.id. This redirected URL will then call the 'results' view to display the final page. Note that you need to use the full name of the view here (including the prefix).'/polls/3/results/'
After somebody votes in a poll, the vote() view redirects to the results page for the poll. Let's write that view:
def results(request, poll_id):
p = get_object_or_404(Poll, pk=poll_id)
return render_to_response('polls/results.html', {'poll': p})Now, create a results.html template:
{{ poll.question }}
- {% for choice in poll.choice_set.all %}
{{ choice.choice }} -- {{ choice.votes }} vote{{ choice.votes|pluralize }} {% endfor %}
Use generic views: Less code is better
The detail() (from Tutorial 3) and results() views are stupidly simple -- and, as mentioned above, redundant. The index() view (also from Tutorial 3), which displays a list of polls, is similar.These views represent a common case of basic Web development: getting data from the database according to a parameter passed in the URL, loading a template and returning the rendered template. Because this is so common, Django provides a shortcut, called the "generic views" system.
Generic views abstract common patterns to the point where you don't even need to write Python code to write an app.
Let's convert our poll app to use the generic views system, so we can delete a bunch of our own code. We'll just have to take a few steps to make the conversion. We will:
- Convert the URLconf.
- Rename a few templates.
- Delete some of the old, unneeded views.
- Fix up URL handling for the new views.
Why the code-shuffle?
Generally, when writing a Django app, you'll evaluate whether generic views are a good fit for your problem, and you'll use them from the beginning, rather than refactoring your code halfway through. But this tutorial intentionally has focused on writing the views "the hard way" until now, to focus on core concepts.You should know basic math before you start using a calculator.
from django.conf.urls.defaults import *
urlpatterns = patterns('mysite.polls.views',
(r'^$', 'index'),
(r'^(?P\d+)/$' , 'detail'),
(r'^(?P\d+)/results/$' , 'results'),
(r'^(?P\d+)/vote/$' , 'vote'),
)from django.conf.urls.defaults import *
from mysite.polls.models import Poll
info_dict = {
'queryset': Poll.objects.all(),
}
urlpatterns = patterns('',
(r'^$', 'django.views.generic.list_detail.object_list', info_dict),
(r'^(?P\d+)/$' , 'django.views.generic.list_detail.object_detail', info_dict),
url(r'^(?P\d+)/results/$' , 'django.views.generic.list_detail.object_detail', dict(info_dict, template_name='polls/results.html'), 'poll_results'),
(r'^(?P\d+)/vote/$' , 'mysite.polls.views.vote'),
)- Each generic view needs to know what data it will be acting upon. This data is provided in a dictionary. The queryset key in this dictionary points to the list of objects to be manipulated by the generic view.
- The object_detail() generic view expects the ID value captured from the URL to be called "object_id", so we've changed poll_id to object_id for the generic views.
- We've added a name, poll_results, to the results view so that we have a way to refer to its URL later on (see the documentation about naming URL patterns for information). We're also using the url() function from django.conf.urls.defaults here. It's a good habit to use url() when you are providing a pattern name like this.
Similarly, the object_list() generic view uses a template called
Because we have more than one entry in the URLconf that uses object_detail() for the polls app, we manually specify a template name for the results view: template_name='polls/results.html'. Otherwise, both views would use the same template. Note that we use dict() to return an altered dictionary in place.
Note
django.db.models.QuerySet.all() is lazyIt might look a little frightening to see Poll.objects.all() being used in a detail view which only needs one Poll object, but don't worry; Poll.objects.all() is actually a special object called a QuerySet, which is "lazy" and doesn't hit your database until it absolutely has to. By the time the database query happens, the object_detail() generic view will have narrowed its scope down to a single object, so the eventual query will only select one row from the database.
If you'd like to know more about how that works, The Django database API documentation explains the lazy nature of QuerySet objects.
You can now delete the index(), detail() and results() views from polls/views.py. We don't need them anymore -- they have been replaced by generic views.
The vote() view is still required. However, it must be modified to match the new context variables. In the render_to_response() call, rename the poll context variable to object.
The last thing to do is fix the URL handling to account for the use of generic views. In the vote view above, we used the reverse() function to avoid hard-coding our URLs. Now that we've switched to a generic view, we'll need to change the reverse() call to point back to our new generic view. We can't simply use the view function anymore -- generic views can be (and are) used multiple times -- but we can use the name we've given:
return HttpResponseRedirect(reverse('poll_results', args=(p.id,)))
