In order to understand how the template system works in conjunction with the rest of the Django framework, we should briefly explore how a request is handled. Understanding this process isn't critical to working with templates, but it will help you make sense of what is happening. This isn't an exhaustive explanation, but it should get us through a basic understanding of what is happening beneath the covers.

Here's how a typical request is handled:

Step 1: A URL is requested

The user requests a web page via URL in his/her browser. The web server receives this request and passes it to Python and Django.

Step 2: The middleware is called

Django has a special mechanism called the middleware that allows you to call functions at a number of places in this request-response cycle. You can invoke a middleware function in four places: before the URL resolution, before the view is called, after the view is called, and if the view raises an exception (if there's a problem).

Step 3: The URL is evaluated

Django's URL dispatcher compares the requested URL with a list of patterns (regular expressions, to be exact). If a match is found, Django imports and calls the view that is associated with the pattern. This process is known as URL resolution.

The view is a Python function that handles the creation of the response. If additional pieces of data have been sent in the URL (such as product IDs, story names, and so on), they are passed as arguments to the function.

Step 4: The middleware is called (again)

If you have middleware functions to be run after URL resolution but before the view is executed, it will be called here.

Step 5: The view is called

The view is where the rubber meets the road, so to speak.

The majority of views will use the database API to perform some kind of CRUD (create, retrieve, update, and delete) operation, load a template, render the output, and send it back to the user.

The Python code in the view function is executed at this point. Usually this entails retrieving some kind of data, most often by using the Django database API to retrieve model objects.

Once the data is retrieved, it is passed to a special object called the Context. This is the object that holds the retrieved data and makes it available to the templates. For now, think of it as a dictionary of variable names and values that the template will get. If you are not familiar with Python dictionaries, see the code notes later in this chapter or look in the Python standard documentation.

Step 6: The template object and template file are loaded

The template object is called and gets the appropriate template file from the file system at the location specified in the view. This relative path is combined with the templates directory specified in our project's settings.py file.

As we discussed earlier in the chapter, templates are not technically required to send back responses, but they make your life much easier. We'll see this in the upcoming examples in this chapter.

Step 7: The template is rendered

The text inside the template is rendered. The placeholders are replaced with their associated data and statements of template logic (such as looping) are performed. At this point, the rendered template is just a large Python string of characters.

Step 8: The middleware is called (again)

If you have middleware functions to be run after the response is generated but before it's sent back to the user, they are called at this step.

Step 9: The output is sent to the browser

The rendered template is packaged up with formatting that is needed by the browser to understand how to accept and display the page. By adding this formatting, the string has been turned into an HTTP response that is sent back to the browser.

In this example, the response is HTML, but it doesn't have to be. It could also be plain text, XML, JavaScript, CSV, PDF, and so on. Part of the formatting of the HTTP response tells the browser what the MIME type of the response is, and it tells the browser what kind of data to expect.