Python プログラマーのための Django テンプレート言語Link to this heading#

変数とルックアップLink to this heading#

変数名はアルファベット(A-Z)、数字(0-9)、アンダースコア(ただしアンダースコアで始まってはならない)、ドットで構成されていなければなりません。

ドットはテンプレートレンダリングにおいて特別な意味を持ちます。変数名のドットは ルックアップ を意味します。具体的には、テンプレートシステムが変数名でドットを見つけると、以下の順番でルックアップを試みます：

• 辞書のルックアップ。例： foo["bar"]

• 属性のルックアップ。例： foo.bar

• リストインデックスのルックアップ。例： foo[bar]

テンプレートコンテキストに変数 "bar "が存在する場合、{{ foo.bar }} のようなテンプレート式中の "bar "はリテラル文字列として解釈され、変数 "bar" の値は使用されないことに注意してください。

テンプレートシステムは、最初に機能するルックアップ・タイプを使用します。これは短絡ロジックです。以下はその例です：

>>> 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."

もし変数のどれかが呼び出し可能オブジェクトであれば、テンプレートシステムは呼び出しを試みます。例：

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

呼び出し可能な変数は、単純なルックアップしか必要としない変数よりも少し複雑です。以下に注意すべき点を示します：

• この変数が呼び出されたときに例外が発生した場合、例外が silent_variable_failure 属性の値が True でない限り、例外は伝播します。例外に silent_variable_failure 属性があり、その値が True である場合、その変数はエンジンの string_if_invalid 設定オプションの値（デフォルトでは空文字列）としてレンダリングされます。例：

  Python console

  >>> 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 ."
  

  django.core.exceptions.ObjectDoesNotExist はすべての Django データベース API の DoesNotExist 例外用の基本クラスですが、 silent_variable_failure = True を持っていることに注意してください。そのため、 Django モデルオブジェクトで Django テンプレートを使っている場合、 DoesNotExist 例外はすべてサイレントエラーになります。

• 変数は必要な引数がない場合のみ呼び出すことができます。そうでない場合、システムはエンジンの string_if_invalid オプションの値を返します。

• いくつかの変数を呼び出すときに副作用が発生する可能性があり、テンプレートシステムがそれらにアクセスできるようにするのは愚策またはセキュリティホールと言えます。

  良い例が、各 Django モデルオブジェクトの delete() メソッドです。テンプレートシステムはこのようなことをしてはいけません：

  Django template

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

  これを防ぐには、呼び出し可能オブジェクトに alters_data 属性を指定します。テンプレートシステムは alters_data=True が設定された変数を呼び出さず、代わりに無条件で string_if_invalid に置き換えます。 動的に生成される Django モデルオブジェクトの delete() と save() メソッドは自動的に alters_data=True を取得します。例：

  Code

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

• 時には、別の理由でこの機能をオフにし、何があっても呼び出されない変数を残すようにテンプレートシステムに指示したいことがあるかもしれません。 そのためには、呼び出し可能オブジェクトの do_not_call_in_templates 属性を True に設定します。 そうすると、テンプレートシステムはあたかも変数が呼び出し可能でないかのように動作します（たとえば、呼び出し可能オブジェクトの属性にアクセスできます）。

無効な変数の扱いLink to this heading#

通常、変数が存在しない場合、テンプレートシステムはエンジンの string_if_invalid 設定オプションの値を挿入します。

string_if_invalid が '' (空文字列) に設定されている場合のみ、無効な変数に適用されるフィルタが適用されます。もし string_if_invalid が他の値に設定されている場合、変数フィルタは無視されます。

この動作は if, for, regroup のテンプレートタグでは少し異なります。これらのテンプレートタグに無効な変数が指定された場合、その変数は None として解釈されます。これらのテンプレートタグ内の無効な変数には常にフィルタが適用されます。

もし string_if_invalid が '%s' を含む場合、フォーマットマーカーは無効な変数名に置き換えられます。

組み込み変数Link to this heading#

すべてのコンテキストは True, False, None を含みます。ご想像の通り、これらの変数は対応する Python オブジェクトに解決されます。

文字列リテラルの制約Link to this heading#

Django のテンプレート言語には、独自の構文に使われる文字をエスケープする手段がありません。例えば、 {% や %} のような文字列を出力する必要がある場合は、 templatetag タグが必要です。

これらのシーケンスをテンプレートフィルタやタグの引数に含めたい場合にも、同じような問題があります。例えば、ブロックタグを解析するとき、 Django のテンプレートパーサは {% の後に %} が最初に現れるかどうかを調べます。これは "%}" が文字列リテラルとして使われるのを阻止します。たとえば、以下のような式では TemplateSyntaxError が発生します：

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

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

フィルタの引数に予約済みのシーケンスを使用すると、同じ問題が発生することがあります：

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

これらのシーケンスで文字列を使用する必要がある場合は、テンプレート変数に格納するか、カスタムテンプレートタグまたはフィルタを使用して制限を回避してください。

RequestContext を使うLink to this heading#

class RequestContext(request, dict_=None, processors=None, use_l10n=None, use_tz=None, autoescape=True)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.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#

コンテキストプロセッサはシンプルなインタフェースを持っています。これは Python の関数で、 HttpRequest オブジェクトを引数に取り、テンプレートコンテキストに追加される辞書を返します。

たとえば、すべてのコンテキストに DEFAULT_FROM_EMAIL 設定を追加するには以下のようにします：

from django.conf import settings


def from_email(request):
    return {
        "DEFAULT_FROM_EMAIL": settings.DEFAULT_FROM_EMAIL,
    }

カスタムコンテキストプロセッサはコードベースのどこにあっても構いません。Django が気にするのは、カスタムコンテキストプロセッサが TEMPLATES 設定の 'context_processors' オプションで指されているかどうか、直接使っている場合は Engine の context_processors 引数で指されているかどうかだけです。

DIRS オプションLink to this heading#

設定ファイルの TEMPLATES 設定にある DIRS オプション、または Engine の dirs 引数を使って、テンプレートディレクトリを Django に教えてください。これはテンプレートディレクトリへのフルパスを含む文字列のリストに設定する必要があります：

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

ディレクトリとテンプレートがWebサーバーによって読み取れる限り、テンプレートはどこに置いても構いません。テンプレートの拡張子は .html や .txt など好きなものを使うことができます。

これらのパスは、Windows でも Unix スタイルのスラッシュ (/) を使う必要があります。

ローダーの種類Link to this heading#

デフォルトでは、 Django はファイルシステムベースのテンプレートローダーを使いますが、 Django には、他のソースからテンプレートを読み込むことができる、他のテンプレートローダーがいくつか付属しています。

これらのローダーのいくつかはデフォルトでは無効になっていますが、 DjangoTemplates バックエンドの TEMPLATES 設定に 'loaders' オプションを追加するか、 Engine に loaders 引数を渡すことで有効にできます。 loaders は文字列かタプルのリストで、それぞれがテンプレートローダークラスを表します。以下は Django に付属のテンプレートローダーです：

django.template.loaders.filesystem.Loader

class filesystem.LoaderLink to this definition#

DIRS に従ってファイルシステムからテンプレートを読み込みます。

このローダーはデフォルトで有効になっています。しかし、 DIRS を空でないリストに設定しないとテンプレートを見つけられません：

Code

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [BASE_DIR / "templates"],
    }
]

また、'DIRS' をオーバーライドして、特定のファイルシステムローダーに特定のディレクトリを指定することもできます：

Code

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "OPTIONS": {
            "loaders": [
                (
                    "django.template.loaders.filesystem.Loader",
                    [BASE_DIR / "templates"],
                ),
            ],
        },
    }
]

django.template.loaders.app_directories.Loader

class app_directories.LoaderLink to this definition#

ファイルシステム上の Django アプリからテンプレートを読み込みます。 INSTALLED_APPS にあるアプリごとに、ローダーは templates サブディレクトリを探します。そのディレクトリが存在すれば、 Django はその中にあるテンプレートを探します。

つまり、テンプレートを個々のアプリと一緒に保存できます。 また、Django アプリをデフォルトのテンプレートと一緒に配布するのにも役立ちます。

たとえば、この設定の場合：

Code

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

...上記のようにすると、get_template('foo.html') はこれらのディレクトリの foo.html をこの順番で探します：

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

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

...そして最初に見つけたものを使います。

INSTALLED_APPS の順序は重要です！例えば、Django管理サイトをカスタマイズしたい場合、django.contrib.admin の標準テンプレート admin/base_site.html を、myproject.polls 内の独自の admin/base_site.html で上書きしたいかもしれません。その場合、myproject.polls が INSTALLED_APPS で django.contrib.admin よりも 前に 来るように確認する必要があります。そうしないと、django.contrib.admin のものが先にロードされ、あなたのものは無視されます。

ローダーは最初に実行されるときに最適化を行うことに注意してください。それは、どの INSTALLED_APPS パッケージが templates サブディレクトリを持っているかのリストをキャッシュします。

このローダーを有効にするには APP_DIRS を True: に設定します：

Code

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

django.template.loaders.cached.Loader

class cached.LoaderLink to this definition#

Django のテンプレートシステムは非常に高速ですが、テンプレートがレンダリングされるたびにテンプレートを読み込んでコンパイルする必要がある場合、そのオーバヘッドは増大する可能性があります。

キャッシュされたテンプレートローダーは、それがラップすべき他のローダーのリストで構成されます。ラップされたローダーは、初めて遭遇した未知のテンプレートを見つけるために使用されます。その後、キャッシュされたローダーはコンパイルされた Template をメモリに保存します。同じテンプレートをロードするための後続のリクエストには、キャッシュされた Template インスタンスが返されます。

このローダーは OPTIONS['loaders'] が指定されていない場合に自動的に有効になります。

カスタムテンプレートローダーでは、以下のような設定を使ってテンプレートのキャッシュを手動で指定できます：

Code

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [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#

Python 辞書からテンプレートを読み込みます。これはテストに便利です。

このローダーはテンプレートの辞書を第一引数に取ります：

Code

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

このローダーはデフォルトでは無効です。

Django は 'loaders' オプションに従って、テンプレートローダーを順番に使用します。一致するローダーが見つかるまで、それぞれのローダーを使います。

ローダーのメソッドLink to this heading#

class LoaderLink to this definition#

ファイルシステムやデータベースなど、指定されたソースからテンプレートを読み込みます。

get_template_sources(template_name)Link to this definition#

テンプレート名 template_name を受け取り、 Origin インスタンスを生成するメソッドです。

例えば、ファイルシステムローダーは template_name 引数として 'index.html' を受け取るかもしれません。このメソッドは、ローダーが見る各テンプレートディレクトリ内の index.html の完全なパスに対してオリジンを生成します。

メソッドは与えられたパスにテンプレートが存在することを確認する必要はありませんが、パスが有効であることを確認する必要があります。例えば、ファイルシステムローダーはパスが有効なテンプレートディレクトリのもとにあることを確認します。

get_contents(origin)Link to this definition#

与えられた Origin に対するテンプレートのコンテンツを返します。

これは、ファイルシステムローダーがファイルシステムから内容を読み取る場所、またはデータベースローダーがデータベースから読み取る場所です。一致するテンプレートが存在しない場合、これは TemplateDoesNotExist エラーを発生させるべきです。

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

get_template_sources() の結果をループして get_contents() を呼び出すことで、与えられた template_name に対応する Template オブジェクトを返します。これは最初にマッチしたテンプレートを返します。テンプレートが見つからない場合、 TemplateDoesNotExist が発生します。

オプションの skip 引数はテンプレートを拡張するときに無視するオリジンのリストです。これにより、テンプレートが同じ名前の他のテンプレートを継承できるようになります。また、再帰エラーを回避するためにも使用されます。

通常、カスタムテンプレートローダーは get_template_sources() と get_contents() を定義すれば十分です。 get_template() は通常オーバーライドする必要はありません。