Django template syntax

Although there are over one hundred built-in constructs that help you build Django templates -- all of which you'll learn as this chapter progresses -- to start out, these are the most important syntax elements you need to recognize:

• {{output_variable}}.- Values surrounded by double curly braces at the start and end represent output for variables. Variables are passed by Django views, url options or context processors into templates. In a template, you can use {{}} to output the contents of a variable, as well as use Python's dot notation to output deeper elements of a variable (e.g. fields, keys, methods). For example, {{store.name}} tells a Django template to output the store variable's name, where store can be an object and name a field or store can be a dictionary and name a key.
• {% tag %} .- Values surrounded by curly braces wrapped with percentage signs are called tags. Django tags offer complex formatting logic wrapped in a simple syntax representation.
• variable|filter .-Values declared after a vertical bar | are called filters. Django filters offer a way to apply formatting logic to individual variables.

Any other syntax in Django templates besides these three variations is treated 'as is'. This means that if a template declares the Hypertext Markup Language (HTML) heading <h1>Welcome!</h1>, a user will get a large HTML heading. It's that simple.

But let's take a look at one not so obvious Django template syntax behavior that's important you understand right away, since it's a recurring theme in practically everything associated with Django templates.

Auto-escaping: HTML and erring on the safe side

Django projects operate on the web, so by default all templates are assumed to produce HTML. While this is a reasonable assumption, it isn't, until you face one of two things:

• You can't ensure Django templates produce valid HTML and in fact may produce dangerous markup.
• You want Django templates to produce non-HTML content, such as Comma Separated Values (CSV), eXtensible Markup Language (XML) or JavaScript Object Notation (JSON).

So how could you possibly introduce invalid HTML or even dangerous content into Django templates ? Well it's the Internet, it's content from other users or providers that can end up in your Django templates that can cause problems (e.g. data submitted by users, third party services, content from databases).

The issue isn't content you place directly in Django templates -- that's given to be valid since you type it in -- the issue is dynamic content placed through variables, tags, filters and context processors, which has the potential to come from anywhere. Let's analyze this further with the following variables: