Writing your first Django app, part 4

This tutorial begins where Tutorial 3 left off. We’recontinuing the Web-poll application and will focus on form processing andcutting down our code.

Write a minimal form

Let’s update our poll detail template (“polls/detail.html”) from the lasttutorial, so that the template contains an HTML <form> element:

polls/templates/polls/detail.html

  1. <h1>{{ question.question_text }}</h1>
  2.  
  3. {% if error_message %}<p><strong>{{ error_message }}</strong></p>{% endif %}
  4.  
  5. <form action="{% url 'polls:vote' question.id %}" method="post">
  6. {% csrf_token %}
  7. {% for choice in question.choice_set.all %}
  8.     <input type="radio" name="choice" id="choice{{ forloop.counter }}" value="{{ choice.id }}">
  9.     <label for="choice{{ forloop.counter }}">{{ choice.choice_text }}</label><br>
  10. {% endfor %}
  11. <input type="submit" value="Vote">
  12. </form>

A quick rundown:

  • The above template displays a radio button for each question choice. Thevalue of each radio button is the associated question choice’s ID. Thename of each radio button is "choice". That means, when somebodyselects one of the radio buttons and submits the form, it’ll send thePOST data choice=# where # is the ID of the selected choice. This is thebasic concept of HTML forms.
  • We set the form’s action to {% url 'polls:vote' question.id %}, and weset method="post". Using method="post" (as opposed tomethod="get") is very important, because the act of submitting thisform will alter data server-side. Whenever you create a form that altersdata server-side, use method="post". This tip isn’t specific toDjango; it’s good Web development practice in general.
  • forloop.counter indicates how many times the for tag has gonethrough its loop
  • Since we’re creating a POST form (which can have the effect of modifyingdata), we need to worry about Cross Site Request Forgeries.Thankfully, you don’t have to worry too hard, because Django comes with ahelpful system for protecting against it. In short, all POST forms that aretargeted at internal URLs should use the {% csrf_token %}template tag.Now, let’s create a Django view that handles the submitted data and doessomething with it. Remember, in Tutorial 3, wecreated a URLconf for the polls application that includes this line:

polls/urls.py

  1. path('<int:question_id>/vote/', views.vote, name='vote'),

We also created a dummy implementation of the vote() function. Let’screate a real version. Add the following to polls/views.py:

polls/views.py

  1. from django.http import HttpResponse, HttpResponseRedirect
  2. from django.shortcuts import get_object_or_404, render
  3. from django.urls import reverse
  4.  
  5. from .models import Choice, Question
  6. # ...
  7. def vote(request, question_id):
  8.     question = get_object_or_404(Question, pk=question_id)
  9.     try:
  10.         selected_choice = question.choice_set.get(pk=request.POST['choice'])
  11.     except (KeyError, Choice.DoesNotExist):
  12.         # Redisplay the question voting form.
  13.         return render(request, 'polls/detail.html', {
  14.             'question': question,
  15.             'error_message': "You didn't select a choice.",
  16.         })
  17.     else:
  18.         selected_choice.votes += 1
  19.         selected_choice.save()
  20.         # Always return an HttpResponseRedirect after successfully dealing
  21.         # with POST data. This prevents data from being posted twice if a
  22.         # user hits the Back button.
  23.         return HttpResponseRedirect(reverse('polls:results', args=(question.id,)))

This code includes a few things we haven’t covered yet in this tutorial:

  • request.POST is a dictionary-likeobject that lets you access submitted data by key name. In this case,request.POST['choice'] returns the ID of the selected choice, as astring. request.POST values arealways 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 onlyaltered via a POST call.

  • request.POST['choice'] will raise KeyError ifchoice wasn’t provided in POST data. The above code checks forKeyError and redisplays the question form with an errormessage if choice isn’t given.

  • After incrementing the choice count, the code returns anHttpResponseRedirect rather than a normalHttpResponse.HttpResponseRedirect takes a single argument: theURL to which the user will be redirected (see the following point for howwe construct the URL in this case).

As the Python comment above points out, you should always return anHttpResponseRedirect after successfully dealing withPOST data. This tip isn’t specific to Django; it’s good Web developmentpractice in general.

  • We are using the reverse() function in theHttpResponseRedirect 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 thevariable portion of the URL pattern that points to that view. In thiscase, using the URLconf we set up in Tutorial 3,this reverse() call will return a string like
  1. '/polls/3/results/'

where the 3 is the value of question.id. This redirected URL willthen call the 'results' view to display the final page.

As mentioned in Tutorial 3, request is anHttpRequest object. For more onHttpRequest objects, see the request andresponse documentation.

After somebody votes in a question, the vote() view redirects to the resultspage for the question. Let’s write that view:

polls/views.py

  1. from django.shortcuts import get_object_or_404, render
  2.  
  3.  
  4. def results(request, question_id):
  5.     question = get_object_or_404(Question, pk=question_id)
  6.     return render(request, 'polls/results.html', {'question': question})

This is almost exactly the same as the detail() view from Tutorial 3. The only difference is the template name. We’ll fix thisredundancy later.

Now, create a polls/results.html template:

polls/templates/polls/results.html

  1. <h1>{{ question.question_text }}</h1>
  2.  
  3. <ul>
  4. {% for choice in question.choice_set.all %}
  5.     <li>{{ choice.choice_text }} -- {{ choice.votes }} vote{{ choice.votes|pluralize }}</li>
  6. {% endfor %}
  7. </ul>
  8.  
  9. <a href="{% url 'polls:detail' question.id %}">Vote again?</a>

Now, go to /polls/1/ in your browser and vote in the question. You should see aresults page that gets updated each time you vote. If you submit the formwithout having chosen a choice, you should see the error message.

Note

The code for our vote() view does have a small problem. It first getsthe selectedchoice object from the database, then computes the newvalue of votes, and then saves it back to the database. If two users ofyour website try to vote at _exactly the same time, this might go wrong:The same value, let’s say 42, will be retrieved for votes. Then, forboth users the new value of 43 is computed and saved, but 44 would be theexpected value.

This is called a race condition. If you are interested, you can readAvoiding race conditions using F() to learn how you can solve thisissue.

Use generic views: Less code is better

The detail() (from Tutorial 3) and results()views are very short – and, as mentioned above, redundant. The index()view, which displays a list of polls, is similar.

These views represent a common case of basic Web development: getting data fromthe database according to a parameter passed in the URL, loading a template andreturning the rendered template. Because this is so common, Django provides ashortcut, called the “generic views” system.

Generic views abstract common patterns to the point where you don’t even needto write Python code to write an app.

Let’s convert our poll app to use the generic views system, so we can delete abunch of our own code. We’ll have to take a few steps to make the conversion.We will:

  • Convert the URLconf.
  • Delete some of the old, unneeded views.
  • Introduce new views based on Django’s generic views.Read on for details.

Why the code-shuffle?

Generally, when writing a Django app, you’ll evaluate whether generic viewsare a good fit for your problem, and you’ll use them from the beginning,rather than refactoring your code halfway through. But this tutorialintentionally has focused on writing the views “the hard way” until now, tofocus on core concepts.

You should know basic math before you start using a calculator.

Amend URLconf

First, open the polls/urls.py URLconf and change it like so:

polls/urls.py

  1. from django.urls import path
  2.  
  3. from . import views
  4.  
  5. app_name = 'polls'
  6. urlpatterns = [
  7.     path('', views.IndexView.as_view(), name='index'),
  8.     path('<int:pk>/', views.DetailView.as_view(), name='detail'),
  9.     path('<int:pk>/results/', views.ResultsView.as_view(), name='results'),
  10.     path('<int:question_id>/vote/', views.vote, name='vote'),
  11. ]

Note that the name of the matched pattern in the path strings of the second andthird patterns has changed from <question_id> to <pk>.

Amend views

Next, we’re going to remove our old index, detail, and resultsviews and use Django’s generic views instead. To do so, open thepolls/views.py file and change it like so:

polls/views.py

  1. from django.http import HttpResponseRedirect
  2. from django.shortcuts import get_object_or_404, render
  3. from django.urls import reverse
  4. from django.views import generic
  5.  
  6. from .models import Choice, Question
  7.  
  8.  
  9. class IndexView(generic.ListView):
  10.     template_name = 'polls/index.html'
  11.     context_object_name = 'latest_question_list'
  12.  
  13.     def get_queryset(self):
  14.         """Return the last five published questions."""
  15.         return Question.objects.order_by('-pub_date')[:5]
  16.  
  17.  
  18. class DetailView(generic.DetailView):
  19.     model = Question
  20.     template_name = 'polls/detail.html'
  21.  
  22.  
  23. class ResultsView(generic.DetailView):
  24.     model = Question
  25.     template_name = 'polls/results.html'
  26.  
  27.  
  28. def vote(request, question_id):
  29.     ... # same as above, no changes needed.

We’re using two generic views here:ListView andDetailView. Respectively, thosetwo views abstract the concepts of “display a list of objects” and“display a detail page for a particular type of object.”

  • Each generic view needs to know what model it will be actingupon. This is provided using the model attribute.
  • The DetailView generic viewexpects the primary key value captured from the URL to be called"pk", so we’ve changed question_id to pk for the genericviews.By default, the DetailView genericview uses a template called <app name>/<model name>_detail.html.In our case, it would use the template "polls/question_detail.html". Thetemplate_name attribute is used to tell Django to use a specifictemplate name instead of the autogenerated default template name. Wealso specify the template_name for the results list view –this ensures that the results view and the detail view have adifferent appearance when rendered, even though they’re both aDetailView behind the scenes.

Similarly, the ListView genericview uses a default template called <app name>/<modelname>_list.html; we use template_name to tellListView to use our existing"polls/index.html" template.

In previous parts of the tutorial, the templates have been providedwith a context that contains the question and latest_question_listcontext variables. For DetailView the question variable is providedautomatically – since we’re using a Django model (Question), Djangois able to determine an appropriate name for the context variable.However, for ListView, the automatically generated context variable isquestion_list. To override this we provide the context_object_nameattribute, specifying that we want to use latest_question_list instead.As an alternative approach, you could change your templates to matchthe new default context variables – but it’s a lot easier to tell Django touse the variable you want.

Run the server, and use your new polling app based on generic views.

For full details on generic views, see the generic views documentation.

When you’re comfortable with forms and generic views, read part 5 of thistutorial to learn about testing our polls app.