Instead of mixing programming code and presentation markup (such as HTML) in the same files, we create templates that have placeholders where the data will go. When the template engine renders the templates, these placeholders are replaced with their appropriate values. By the time the output is returned to the web browser, all traces of the template have been removed, leaving only the resulting output.

As we have seen, Django templates, typically, are files loaded by the template engine and rendered into output that will be sent back to the browser. This loading and rendering takes place in the view, the function that Django calls to fulfill requests.

In order to accomplish basic output logic, such as looping through records and creating table rows, some programming code needs to exist in the template files. The amount of programming you can do in your template depends on your programming language or framework; Django allows basic looping and conditional logic. The process of rendering executes this template logic and replaces placeholders with data.

By separating templates out of framework code into their own files, developers and designers can work simultaneously on the same project without stepping on each other's work. This approach has the added benefit that there is a clear differentiation between design and development; coders stay out of the design arena and designers stay out of the programming arena—we can live in harmony! (Well, maybe...)

Keeping the template clear of code also makes it easier to work in WYSIWYG (What You See Is What You Get) editors such as Dreamweaver and Homesite. We're not going to cover that in the book, but it's worth mentioning.

The template files are usually located in their own folders nested somewhere in the Django project. The templates can include other templates in them, and so common page elements such as menus, headers, and footers can be kept in their own files. Including common elements from single files increases the maintainability of our application by reducing the amount of common output markup that is duplicated in different files. Instead of hunting around for all the occurrences of some HTML to replace, we can make the change in one place and all templates that include the content will be updated automatically.

Templates can also have parent templates that simplify the development of sections of a site. For example, if we have a calendar listing in the events section of a website, we might use three templates:

This prevents the duplication of site- and section-wide HTML by keeping them in single files. We'll explore the parent-child relationship and inheritance of templates in great detail in a later chapter.

The syntax of the template system is intentionally clean, simple, and elegant. With a minimal understanding of programming concepts, you can make powerful and flexible templates to output your data.

We'll cover these concepts and the syntax of the template language later in this chapter.

Django ships with many built-in template elements that we can use to control and format the output of our templates. You can also write your own template elements, if you have a need that isn't met by the default libraries, or use ones that other developers have written. Sites such as DjangoSnippets.org contain many template libraries that developers have shared and can be easily incorporated into your own site.

In a later chapter, we'll cover writing your own template element libraries and how to install and use libraries that others have written.

The template system is flexible enough so that we can output any kind of data that we want. It doesn't assume (or require) that you are going to produce HTML. We can dynamically generate PDF documents, CSV files, HTML files, microformats, and text documents. It also doesn't require you to write your templates in any specific format (such as XML) the way some other Python templating languages do.

Even though you can extend the template system with custom elements to fit your needs, the Django creators gave us the ultimate back door—You don't have to use their template system! You are free to implement any Python template system and libraries of your choice, and you can do it on an as-needed basis in only the places you desire. For example, if you want to use the Django template system for half of your views and the open-source Genshi templating system for the other half, there's no penalty.

The elegance and simplicity of the Django template system comes at a price; there are a few limitations to be aware of. In a nutshell, only the processing of simple presentation logic is supported in templates. You can loop over sets of data and check the value of objects and variables to perform conditional logic, but you cannot perform complex logic and execute raw Python code.

Here are a few things you cannot do using the Django template system syntax:

If you need to perform these kinds of actions, you can often write your own extensions to the template system. We will fully cover these limitations and their implications later in the book.

Some critics argue that the Django template system is too simple and isn't robust enough to perform complex formatting or outputting. This may be true, but remember that these limitations are intentional to achieve the design goals we discussed earlier. You're also free not to use Django's template system and use a more liberal template library if you choose.