The Django template language: for Python programmersLink to this heading#

Variables and lookupsLink to this heading#

Variable names must consist of any letter (A-Z), any digit (0-9), an underscore (but they must not start with an underscore) or a dot.

Dots have a special meaning in template rendering. A dot in a variable name signifies a lookup. Specifically, when the template system encounters a dot in a variable name, it tries the following lookups, in this order:

• Dictionary lookup. Example: foo["bar"]

• Attribute lookup. Example: foo.bar

• List-index lookup. Example: foo[bar]

Note that "bar" in a template expression like {{ foo.bar }} will be interpreted as a literal string and not using the value of the variable "bar", if one exists in the template context.

The template system uses the first lookup type that works. It's short-circuit logic. Here are a few examples:

>>> from django.template import Context, Template
>>> t = Template("My name is {{ person.first_name }}.")
>>> d = {"person": {"first_name": "Joe", "last_name": "Johnson"}}
>>> t.render(Context(d))
"My name is Joe."

>>> class PersonClass: pass
>>> p = PersonClass()
>>> p.first_name = "Ron"
>>> p.last_name = "Nasty"
>>> t.render(Context({"person": p}))
"My name is Ron."

>>> t = Template("The first stooge in the list is {{ stooges.0 }}.")
>>> c = Context({"stooges": ["Larry", "Curly", "Moe"]})
>>> t.render(c)
"The first stooge in the list is Larry."

If any part of the variable is callable, the template system will try calling it. Example:

>>> class PersonClass2:
...     def name(self):
...         return "Samantha"
>>> t = Template("My name is {{ person.name }}.")
>>> t.render(Context({"person": PersonClass2}))
"My name is Samantha."

Callable variables are slightly more complex than variables which only require straight lookups. Here are some things to keep in mind:

• If the variable raises an exception when called, the exception will be propagated, unless the exception has an attribute silent_variable_failure whose value is True. If the exception does have a silent_variable_failure attribute whose value is True, the variable will render as the value of the engine's string_if_invalid configuration option (an empty string, by default). Example:

  Code

  >>> t = Template("My name is {{ person.first_name }}.")
  >>> class PersonClass3:
  ...     def first_name(self):
  ...         raise AssertionError("foo")
  >>> p = PersonClass3()
  >>> t.render(Context({"person": p}))
  Traceback (most recent call last):
  ...
  AssertionError: foo
  
  >>> class SilentAssertionError(Exception):
  ...     silent_variable_failure = True
  >>> class PersonClass4:
  ...     def first_name(self):
  ...         raise SilentAssertionError
  >>> p = PersonClass4()
  >>> t.render(Context({"person": p}))
  "My name is ."
  

  Note that django.core.exceptions.ObjectDoesNotExist, which is the base class for all Django database API DoesNotExist exceptions, has silent_variable_failure = True. So if you're using Django templates with Django model objects, any DoesNotExist exception will fail silently.

• A variable can only be called if it has no required arguments. Otherwise, the system will return the value of the engine's string_if_invalid option.

• Obviously, there can be side effects when calling some variables, and it'd be either foolish or a security hole to allow the template system to access them.

  A good example is the delete() method on each Django model object. The template system shouldn't be allowed to do something like this:

  Code

  I will now delete this valuable data. {{ data.delete }}
  

  To prevent this, set an alters_data attribute on the callable variable. The template system won't call a variable if it has alters_data=True set, and will instead replace the variable with string_if_invalid, unconditionally. The dynamically-generated delete() and save() methods on Django model objects get alters_data=True automatically. Example:

  Code

  def sensitive_function(self):
      self.database_record.delete()
  sensitive_function.alters_data = True
  

• Occasionally you may want to turn off this feature for other reasons, and tell the template system to leave a variable uncalled no matter what. To do so, set a do_not_call_in_templates attribute on the callable with the value True. The template system then will act as if your variable is not callable (allowing you to access attributes of the callable, for example).

How invalid variables are handledLink to this heading#

Generally, if a variable doesn't exist, the template system inserts the value of the engine's string_if_invalid configuration option, which is set to '' (the empty string) by default.

Filters that are applied to an invalid variable will only be applied if string_if_invalid is set to '' (the empty string). If string_if_invalid is set to any other value, variable filters will be ignored.

This behavior is slightly different for the if, for and regroup template tags. If an invalid variable is provided to one of these template tags, the variable will be interpreted as None. Filters are always applied to invalid variables within these template tags.

If string_if_invalid contains a '%s', the format marker will be replaced with the name of the invalid variable.

Built-in variablesLink to this heading#

Every context contains True, False and None. As you would expect, these variables resolve to the corresponding Python objects.

Limitations with string literalsLink to this heading#

Django's template language has no way to escape the characters used for its own syntax. For example, the templatetag tag is required if you need to output character sequences like {% and %}.

A similar issue exists if you want to include these sequences in template filter or tag arguments. For example, when parsing a block tag, Django's template parser looks for the first occurrence of %} after a {%. This prevents the use of "%}" as a string literal. For example, a TemplateSyntaxError will be raised for the following expressions:

{% include "template.html" tvar="Some string literal with %} in it." %}

{% with tvar="Some string literal with %} in it." %}{% endwith %}

The same issue can be triggered by using a reserved sequence in filter arguments:

{{ some.variable|default:"}}" }}

If you need to use strings with these sequences, store them in template variables or use a custom template tag or filter to workaround the limitation.

RequestContext を使うLink to this heading#

class RequestContext(request, dict_=None, processors=None)Link to this definition#

Django では特別な Context クラスである django.template.RequestContext が使えます。これは、通常の django.template.Context とはいくつかの点で異なります。最初の違いは、最初の引数として HttpRequest を取ることです。例えば:

c = RequestContext(request, {
    'foo': 'bar',
})

2 つめの違いは、エンジンの context_processors 設定オプションによって、昆的に自動的にいくつかの変数をセットすることです。

context_processors オプションは callable -- context processors と呼ばれます -- のリストで、引数としてリクエストオブジェクトを受け取り、コンテキストに統合する項目のディクショナリを返します。 デフォルトで生成される設定ファイルでは、テンプレートエンジンは以下のコンテキストプロセッサを含んでいます:

[
    'django.template.context_processors.debug',
    'django.template.context_processors.request',
    'django.contrib.auth.context_processors.auth',
    'django.contrib.messages.context_processors.messages',
]

上記に加えて、RequestContext は常に 'django.template.context_processors.csrf' を使えるようにしています。これは、admin や他の contrib アプリケーションで必要な、セキュリティ関連のコンテキストプロセッサで、設定ミスの場合に備えて意図的にハードコードされており、context_processors オプション内で無効化できないようになっています。

各プロセッサは順番通りに適用されます。したがって、1 番目と 2 番目のプロセッサがそれぞれ同じ名前の変数をコンテキストに追加したとき、2 番目の変数が 1 番目をオーバーライドします。デフォルトのプロセッサは以下で説明します。

また、省略可能な第 3 引数 processors を使って、RequestContext に追加的なプロセッサを渡すこともできます。以下の例では、RequestContext のインスタンスは ip_address 変数を格納します:

from django.http import HttpResponse
from django.template import RequestContext, Template

def ip_address_processor(request):
    return {'ip_address': request.META['REMOTE_ADDR']}

def client_ip_view(request):
    template = Template('{{ title }}: {{ ip_address }}')
    context = RequestContext(request, {
        'title': 'Your IP Address',
    }, [ip_address_processor])
    return HttpResponse(template.render(context))

ビルトインのテンプレートコンテキストプロセッサLink to this heading#

以下は、それぞれのビルトインのプロセッサが行うことです:

独自のコンテキストプロセッサを記述するLink to this heading#

A context processor has a very simple interface: It's a Python function that takes one argument, an HttpRequest object, and returns a dictionary that gets added to the template context. Each context processor must return a dictionary.

Custom context processors can live anywhere in your code base. All Django cares about is that your custom context processors are pointed to by the 'context_processors' option in your TEMPLATES setting — or the context_processors argument of Engine if you're using it directly.

The DIRS optionLink to this heading#

Tell Django what your template directories are by using the DIRS option in the TEMPLATES setting in your settings file — or the dirs argument of Engine. This should be set to a list of strings that contain full paths to your template directories:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
            '/home/html/templates/lawrence.com',
            '/home/html/templates/default',
        ],
    },
]

Your templates can go anywhere you want, as long as the directories and templates are readable by the Web server. They can have any extension you want, such as .html or .txt, or they can have no extension at all.

Note that these paths should use Unix-style forward slashes, even on Windows.

Loader typesLink to this heading#

By default, Django uses a filesystem-based template loader, but Django comes with a few other template loaders, which know how to load templates from other sources.

Some of these other loaders are disabled by default, but you can activate them by adding a 'loaders' option to your DjangoTemplates backend in the TEMPLATES setting or passing a loaders argument to Engine. loaders should be a list of strings or tuples, where each represents a template loader class. Here are the template loaders that come with Django:

django.template.loaders.filesystem.Loader

class filesystem.LoaderLink to this definition#

Loads templates from the filesystem, according to DIRS.

This loader is enabled by default. However it won't find any templates until you set DIRS to a non-empty list:

Code

TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'DIRS': [os.path.join(BASE_DIR, 'templates')],
}]

You can also override 'DIRS' and specify specific directories for a particular filesystem loader:

Code

TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'OPTIONS': {
        'loaders': [
            (
                'django.template.loaders.filesystem.Loader',
                [os.path.join(BASE_DIR, 'templates')],
            ),
        ],
    },
}]

django.template.loaders.app_directories.Loader

class app_directories.LoaderLink to this definition#

Loads templates from Django apps on the filesystem. For each app in INSTALLED_APPS, the loader looks for a templates subdirectory. If the directory exists, Django looks for templates in there.

This means you can store templates with your individual apps. This also makes it easy to distribute Django apps with default templates.

For example, for this setting:

Code

INSTALLED_APPS = ['myproject.polls', 'myproject.music']

...then get_template('foo.html') will look for foo.html in these directories, in this order:

• /path/to/myproject/polls/templates/

• /path/to/myproject/music/templates/

... and will use the one it finds first.

The order of INSTALLED_APPS is significant! For example, if you want to customize the Django admin, you might choose to override the standard admin/base_site.html template, from django.contrib.admin, with your own admin/base_site.html in myproject.polls. You must then make sure that your myproject.polls comes before django.contrib.admin in INSTALLED_APPS, otherwise django.contrib.admin’s will be loaded first and yours will be ignored.

Note that the loader performs an optimization when it first runs: it caches a list of which INSTALLED_APPS packages have a templates subdirectory.

You can enable this loader simply by setting APP_DIRS to True:

Code

TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'APP_DIRS': True,
}]

django.template.loaders.eggs.Loader

class eggs.LoaderLink to this definition#

Just like app_directories above, but it loads templates from Python eggs rather than from the filesystem.

This loader is disabled by default.

django.template.loaders.cached.Loader

class cached.LoaderLink to this definition#

By default (when DEBUG is True), the template system reads and compiles your templates every time they're rendered. While the Django template system is quite fast, the overhead from reading and compiling templates can add up.

You configure the cached template loader with a list of other loaders that it should wrap. The wrapped loaders are used to locate unknown templates when they're first encountered. The cached loader then stores the compiled Template in memory. The cached Template instance is returned for subsequent requests to load the same template.

This loader is automatically enabled if OPTIONS['loaders'] isn't specified and OPTIONS['debug'] is False (the latter option defaults to the value of DEBUG).

You can also enable template caching with some custom template loaders using settings like this:

Code

TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'DIRS': [os.path.join(BASE_DIR, 'templates')],
    'OPTIONS': {
        'loaders': [
            ('django.template.loaders.cached.Loader', [
                'django.template.loaders.filesystem.Loader',
                'django.template.loaders.app_directories.Loader',
                'path.to.custom.Loader',
            ]),
        ],
    },
}]

django.template.loaders.locmem.Loader

class locmem.LoaderLink to this definition#

Loads templates from a Python dictionary. This is useful for testing.

This loader takes a dictionary of templates as its first argument:

Code

TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'OPTIONS': {
        'loaders': [
            ('django.template.loaders.locmem.Loader', {
                'index.html': 'content here',
            }),
        ],
    },
}]

This loader is disabled by default.

Django uses the template loaders in order according to the 'loaders' option. It uses each loader until a loader finds a match.

Loader methodsLink to this heading#

class LoaderLink to this definition#

Loads templates from a given source, such as the filesystem or a database.

get_template_sources(template_name)Link to this definition#

A method that takes a template_name and yields Origin instances for each possible source.

For example, the filesystem loader may receive 'index.html' as a template_name argument. This method would yield origins for the full path of index.html as it appears in each template directory the loader looks at.

The method doesn't need to verify that the template exists at a given path, but it should ensure the path is valid. For instance, the filesystem loader makes sure the path lies under a valid template directory.

get_contents(origin)Link to this definition#

Returns the contents for a template given a Origin instance.

This is where a filesystem loader would read contents from the filesystem, or a database loader would read from the database. If a matching template doesn't exist, this should raise a TemplateDoesNotExist error.

get_template(template_name, skip=None)Link to this definition#

Returns a Template object for a given template_name by looping through results from get_template_sources() and calling get_contents(). This returns the first matching template. If no template is found, TemplateDoesNotExist is raised.

The optional skip argument is a list of origins to ignore when extending templates. This allow templates to extend other templates of the same name. It also used to avoid recursion errors.

In general, it is enough to define get_template_sources() and get_contents() for custom template loaders. get_template() will usually not need to be overridden.

load_template_source(template_name, template_dirs=None)Link to this definition#

Returns a tuple of (template_string, template_origin), where template_string is a string containing the template contents, and template_origin is a string identifying the template source. A filesystem-based loader may return the full path to the file as the template_origin, for example.

template_dirs is an optional argument used to control which directories the loader will search.

This method is called automatically by load_template() and should be overridden when writing custom template loaders.

load_template(template_name, template_dirs=None)Link to this definition#

Returns a tuple of (template, template_origin), where template is a Template object and template_origin is a string identifying the template source. A filesystem-based loader may return the full path to the file as the template_origin, for example.