A view is a “type” of Web page in your Django application that generally serves
a specific function and has a specific template. For example, in a blog
application, you might have the following views:

Blog homepage – displays the latest few entries.

Entry “detail” page – permalink page for a single entry.

Year-based archive page – displays all months with entries in the
given year.

Month-based archive page – displays all days with entries in the
given month.

Day-based archive page – displays all entries in the given day.

Comment action – handles posting comments to a given entry.

In our poll application, we’ll have the following four views:

Question “index” page – displays the latest few questions.

Question “detail” page – displays a question text, with no results but
with a form to vote.

Question “results” page – displays results for a particular question.

Vote action – handles voting for a particular choice in a particular
question.

In Django, web pages and other content are delivered by views. Each view is
represented by a simple 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).

Now in your time on the web you may have come across such beauties as
“ME2/Sites/dirmod.asp?sid=&type=gen&mod=Core+Pages&gid=A6CD4967199A42D9B65B1B”.
You will be pleased to know that Django allows us much more elegant
URL patterns than that.

A URL pattern is simply the general form of a URL - for example:
/newsarchive/<year>/<month>/.

To get from a URL to a view, Django uses what are known as ‘URLconfs’. A
URLconf maps URL patterns (described as regular expressions) to views.

This tutorial provides basic instruction in the use of URLconfs, and you can
refer to django.core.urlresolvers for more information.

If you’re seeing admin.autodiscover() before the definition of
urlpatterns, you’re probably using a version of Django that doesn’t
match this tutorial version. You’ll want to either switch to the older
tutorial or the newer Django version.

You have now wired an index view into the URLconf. Go to
http://localhost:8000/polls/ in your browser, and you should see the text
“Hello, world. You’re at the polls index.”, which you defined in the
index view.

The url() function is passed four arguments, two
required: regex and view, and two optional: kwargs, and name.
At this point, it’s worth reviewing what these arguments are for.

The term “regex” is a commonly used short form meaning “regular expression”,
which is a syntax for matching patterns in strings, or in this case, url
patterns. Django starts at the first regular expression and makes its way down
the list, comparing the requested URL against each regular expression until it
finds one that matches.

Note that these regular expressions do not search GET and POST parameters, or
the domain name. For example, in a request to
http://www.example.com/myapp/, the URLconf will look for myapp/. In a
request to http://www.example.com/myapp/?page=3, the URLconf will also
look for myapp/.

If you need help with regular expressions, see Wikipedia’s entry and the
documentation of the re module. Also, the O’Reilly book “Mastering
Regular Expressions” by Jeffrey Friedl is fantastic. In practice, however,
you don’t need to be an expert on regular expressions, as you really only need
to know how to capture simple patterns. In fact, complex regexes can have poor
lookup performance, so you probably shouldn’t rely on the full power of regexes.

Finally, a performance note: these regular expressions are compiled the first
time the URLconf module is loaded. They’re super fast (as long as the lookups
aren’t too complex as noted above).

When Django finds a regular expression match, Django calls the specified view
function, with an HttpRequest object as the first
argument and any “captured” values from the regular expression as other
arguments. If the regex uses simple captures, values are passed as positional
arguments; if it uses named captures, values are passed as keyword arguments.
We’ll give an example of this in a bit.

Naming your URL lets you refer to it unambiguously from elsewhere in Django
especially templates. This powerful feature allows you to make global changes
to the url patterns of your project while only touching a single file.

Take a look in your browser, at “/polls/34/”. It’ll run the detail()
method and display whatever ID you provide in the URL. Try
“/polls/34/results/” and “/polls/34/vote/” too – these will display the
placeholder results and voting pages.

When somebody requests a page from your Web site – say, “/polls/34/”, Django
will load the mysite.urls Python module because it’s pointed to by the
ROOT_URLCONF setting. It finds the variable named urlpatterns
and traverses the regular expressions in order. The
include() functions we are using simply reference
other URLconfs. Note that the regular expressions for the
include() functions don’t have a $ (end-of-string
match character) but rather a trailing slash. Whenever Django encounters
include(), it chops off whatever part of the URL
matched up to that point and sends the remaining string to the included
URLconf for further processing.

The idea behind include() is to make it easy to
plug-and-play URLs. Since polls are in their own URLconf
(polls/urls.py), they can be placed under “/polls/”, or under
“/fun_polls/”, or under “/content/polls/”, or any other path root, and the
app will still work.

Here’s what happens if a user goes to “/polls/34/” in this system:

Django will find the match at '^polls/'

Then, Django will strip off the matching text ("polls/") and send the
remaining text – "34/" – to the ‘polls.urls’ URLconf for
further processing which matches r'^(?P<question_id>\d+)/$' resulting in a
call to the detail() view like so:

detail(request=<HttpRequest object>, question_id='34')

The question_id='34' part comes from (?P<question_id>\d+). Using parentheses
around a pattern “captures” the text matched by that pattern and sends it as an
argument to the view function; ?P<question_id> defines the name that will
be used to identify the matched pattern; and \d+ is a regular expression to
match a sequence of digits (i.e., a number).

Because the URL patterns are regular expressions, there really is no limit on
what you can do with them. And there’s no need to add URL cruft such as
.html – unless you want to, in which case you can do something like
this:

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. The
rest is up to you.

Your view can read records from a database, or not. It can use a template
system such as Django’s – or a third-party Python template system – or not.
It can generate a PDF file, output XML, create a ZIP file on the fly, anything
you want, using whatever Python libraries you want.

Because it’s convenient, let’s use Django’s own database API, which we covered
in Tutorial 1. Here’s one stab at a new index()
view, which displays the latest 5 poll questions in the system, separated by
commas, according to publication date:

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.

We could have all our templates together, in one big templates directory,
and it would work perfectly well. However, this template belongs to the
polls application, so unlike the admin template we created in the previous
tutorial, we’ll put this one in the application’s template directory
(polls/templates) rather than the project’s (templates). We’ll
discuss in more detail in the reusable apps tutorialwhy we do this.

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 simply as polls/index.html.

Template namespacing

Now we might be able to get away with putting our templates directly in
polls/templates (rather than creating another polls subdirectory),
but it would actually be a bad idea. Django will choose the first template
it finds whose name matches, and if you had a template with the same name
in a different application, Django would be unable to distinguish between
them. We need to be able to point Django at the right one, and the easiest
way to ensure this is by namespacing them. That is, by putting those
templates inside another directory named for the application itself.

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:

Note that once we’ve done this in all these views, we no longer need to import
loader, RequestContext 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:

polls/views.py

fromdjango.httpimportHttp404fromdjango.shortcutsimportrenderfrompolls.modelsimportQuestion# ...defdetail(request,question_id):try:question=Question.objects.get(pk=question_id)exceptQuestion.DoesNotExist:raiseHttp404("Question does not exist")returnrender(request,'polls/detail.html',{'question':question})

The new concept here: The view raises the Http404 exception
if a question with the requested ID doesn’t exist.

We’ll discuss what you could put in that polls/detail.html template a bit
later, but if you’d like to quickly get the above example working, a file
containing just:

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.

Because that would couple the model layer to the view layer. One of the
foremost design goals of Django is to maintain loose coupling. Some
controlled coupling is introduced in the django.shortcuts module.

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.

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 url() 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:

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:

...# the 'name' value as called by the {% url %} template tagurl(r'^(?P<question_id>\d+)/$',views.detail,name='detail'),...

If you want to change the URL of the polls detail view to something else,
perhaps to something like polls/specifics/12/ instead of doing it in the
template (or templates) you would change it in polls/urls.py:

The tutorial project has just one app, polls. In real Django projects,
there might be five, ten, twenty apps or 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 root URLconf. In the mysite/urls.py
file, go ahead and change it to include namespacing: