Django Views

Django’s views are the information brokers of a Django application. A view sources data from your database (or an external data source or service) and delivers it to a template. For a web application, the view delivers web page content and templates, for a RESTful API, this content could be properly formatted JSON data.

The view makes decisions on what data gets delivered to the template—either by acting on input from the user, or in response to other business logic and internal processes.

Each Django view performs a specific function, and has an associated template. Views are represented by either a Python function, or a method of a Python class. In the early days of Django, there were only function-based views, however as Django has grown over the years, Django’s developers added class-based views to Django.

Class-based views add extensibility to Django’s views, as well as built-in views that make creating common views (like displaying a list of articles) easier to implement.

To ease the burden on programmers, many common display tasks have built-in views in Django. There are four built-in function based views for displaying error pages:

• The 404 (page not found) view
• The 500 (server error) view
• The 403 (HTTP Forbidden) view
• The 400 (bad request) view

There are also several class-based views for simplifying common display tasks. They include:

• ListView for displaying a list of data objects (e.g. list all articles)
• DetailView for displaying a single object (e.g. individual article)
• RedirectView redirects to another URL
• FormView for displaying a form

Additional class-based generic date views for showing day, week, month and yearly collections of objects like blog posts and articles are also provided.

URLconf—Tying it all Together

Our website is not much use if we can’t navigate around it—we need to tell the view what to display in the browser, based on what the user has requested.

Navigation in a Django website is the same as any other website—pages and other content are accessed via URL. When a user clicks on a link on a website, a request for that URL is sent to Django (Figure shown below).

Figure  The browser request for you site homepage is sent directly to Django.

Once Django receives the requested URL, it must decide which view will deal with the request. You, as the programmer, decide which view to serve at which URL by creating a URL Configuration (URLconf for short) in a Python file named urls.py (Figure shown below). When Django finds a URL in urls.py that matches the requested URL, it calls the view associated with that URL.

Figure  Django maps the requested URL to a view.

The selected view then renders the content to a template, as per the business logic in the view and sends the rendered content back to your browser for display (Figure shown below).

Figure  The view then tells Django what template to use when sending content back to the browser.

Of course, this is a simplification—Django can collect much more complex data from the browser than a URL, and views don’t just render web pages. There is also a whole other layer of Django goodness that sits between the browser request and your view’s response (which Django rather cleverly calls middleware) that allows you to do tons of cool stuff with your data, but these are advanced topics for another book.

The takeaway here is, regardless of how complex a website gets, this simple process underlies all of the communication between Django, the browser and the end user.

So that’s about it for our high level look at the structure of Django and how Django communicates with the browser to show your site content.