In Django, web pages and other content
are delivered by views. Each view is represented by a Python function (or
method, in the case of class-based views). Django will choose a view by
examining the URL that’s requested (to be precise, the part of the URL after
the domain name). To get from a URL to a view, Django uses what are known as
‘URLconfs’. A URLconf maps URL patterns to views.
Now let’s add a few more views to
polls/views.py:
def detail(request, question_id):
return
HttpResponse("You're looking at question %s." % question_id)
def results(request, question_id):
response
= "You're looking at the results of question %s."
return
HttpResponse(response % question_id)
def vote(request, question_id):
return
HttpResponse("You're voting on question %s." % question_id)
Next we’ll wire these new views into the
polls.urls module by adding the following path() calls:
path('<int:question_id>/', views.detail, name='detail'),
path('<int:question_id>/results/', views.results, name='results'),
path('<int:question_id>/vote/', views.vote, name='vote'),
Each view is responsible for doing one
of two things: returning an HttpResponse object containing the content for the
requested page, or raising an exception such as Http404. If we want we can
modify our index() view, so that it displays the latest 5 poll questions in the
system, separated by commas, according to publication date:
def index(request):
latest_question_list
= Question.objects.order_by('-pub_date')[:5]
output
= ', '.join([q.question_text for q in latest_question_list])
return
HttpResponse(output)
There’s a problem here, though: the
page’s design is hard-coded in the view. If you want to change the way the page
looks, you’ll have to edit this Python code. So let’s use Django’s template
system to separate the design from Python by creating a template that the view
can use.
First, create a directory called
templates in your polls directory. Django will look for templates in there.
Your project’s TEMPLATES setting
describes how Django will load and render templates. The default settings file
configures a DjangoTemplates backend whose APP_DIRS option is set to True. By
convention DjangoTemplates looks for a “templates” subdirectory in each of the
INSTALLED_APPS.
Within the templates directory you have
just created, create another directory called polls, and within that create a
file called index.html. In other words, your template should be at
polls/templates/polls/index.html. Because of how the app_directories template
loader works as described above, you can refer to this template within Django
as polls/index.html. Put the following code in that template:
{% if latest_question_list %}
<ul>
{% for question in latest_question_list %}
<li><a href="/polls/{{ question.id }}/">{{ question.question_text }}</a></li>
{% endfor %}
</ul>
{% else %}
<p>No polls are available.</p>
{% endif %}
Now let’s update our index view in
polls/views.py to use the template:
def index(request):
latest_question_list
= Question.objects.order_by('-pub_date')[:5]
template
= loader.get_template('polls/index.html')
context
= {
'latest_question_list': latest_question_list,
}
return
HttpResponse(template.render(context, request))
That code loads the template called
polls/index.html and passes it a context. The context is a dictionary mapping
template variable names to Python objects. Load the page by pointing your
browser at “/polls/”, and you should see a bulleted-list containing the created
question in the previous post.
It’s a very common idiom to load a
template, fill a context and return an HttpResponse object with the result of
the rendered template. Django provides a shortcut. Here’s the full index()
view, rewritten:
def index(request):
latest_question_list
= Question.objects.order_by('-pub_date')[:5]
context = {'latest_question_list': latest_question_list}
return render(request, 'polls/index.html', context)
Note that once we’ve done this in all
these views, we no longer need to import loader and HttpResponse (you’ll want
to keep HttpResponse if you still have the stub methods for detail, results,
and vote).
The render() function takes the request
object as its first argument, a template name as its second argument and a
dictionary as its optional third argument. It returns an HttpResponse object of
the given template rendered with the given context.
Now, let’s tackle the question detail
view – the page that displays the question text for a given poll. Here’s the
view:
from django.http import Http404
from django.shortcuts import render
from .models import Question
# ...
def detail(request, question_id):
try:
question = Question.objects.get(pk=question_id)
except Question.DoesNotExist:
raise Http404("Question does not exist")
return render(request,
'polls/detail.html', {'question': question})
The view raises the Http404 exception if
a question with the requested ID doesn’t exist. It’s a very common idiom to use
get() and raise Http404 if the object doesn’t exist. Django provides a
shortcut. Here’s the detail() view, rewritten:
def detail(request, question_id):
question
= get_object_or_404(Question, pk=question_id)
return
render(request, 'polls/detail.html', {'question': question})
The get_object_or_404() function takes a
Django model as its first argument and an arbitrary number of keyword
arguments, which it passes to the get() function of the model’s manager. It
raises Http404 if the object doesn’t exist.
There’s also a get_list_or_404()
function, which works just as get_object_or_404() – except using filter()
instead of get(). It raises Http404 if the list is empty. Back to the detail()
view for our poll application. Given the context variable question, here’s what
the polls/detail.html template might look like:
<h1>{{ question.question_text
}}</h1>
<ul>
{% for choice in question.choice_set.all
%}
<li>{{ choice.choice_text }}</li>
{% endfor %}
</ul>
The template system uses dot-lookup
syntax to access variable attributes. In the example of {{
question.question_text }}, first Django does a dictionary lookup on the object
question. Failing that, it tries an attribute lookup – which works, in this
case. If attribute lookup had failed, it would’ve tried a list-index lookup.
Method-calling happens in the {% for %}
loop: question.choice_set.all is interpreted as the Python code
question.choice_set.all(), which returns an iterable of Choice objects and is
suitable for use in the {% for %} tag.
Remember, when we wrote the link to a
question in the polls/index.html template, the link was partially hardcoded
like this:
<li><a href="/polls/{{
question.id }}/">{{ question.question_text }}</a></li>
The problem with this hardcoded,
tightly-coupled approach is that it becomes challenging to change URLs on
projects with a lot of templates. However, since you defined the name argument
in the path() functions in the polls.urls module, you can remove a reliance on
specific URL paths defined in your url configurations by using the {% url %}
template tag:
<li><a href="{% url
'detail' question.id %}">{{ question.question_text
}}</a></li>
The way this works is by looking up the
URL definition as specified in the polls.urls module. You can see exactly where
the URL name of ‘detail’ is defined below:
path('<int:question_id>/',
views.detail, name='detail'),
Our project has just one app, polls but in
real Django projects, there might be more. How does Django differentiate the
URL names between them? For example, the polls app has a detail view, and so
might an app on the same project that is for a blog. How does one make it so
that Django knows which app view to create for a url when using the {% url %}
template tag?
The answer is to add namespaces to your
URLconf. In the polls/urls.py file, go ahead and add an app_name to set the
application namespace:
app_name = 'polls'
Now change your polls/index.html
template to point at the namespaced detail view:
<li><a href="{% url
'polls:detail' question.id %}">{{ question.question_text
}}</a></li>
In the next post we’ll learn the basics
about form processing and generic views.
