This document explains the Django template system from a technical\nperspective – how it works and how to extend it. If you’re looking for\nreference on the language syntax, see The Django template language.
\nIt assumes an understanding of templates, contexts, variables, tags, and\nrendering. Start with the introduction to the Django template language if you aren’t familiar with these concepts.
\nUsing the template system in Python is a three-step process:
\nYou configure an Engine.
You compile template code into a Template.
You render the template with a Context.
Django projects generally rely on the high level, backend agnostic APIs for each of these steps instead of the template system’s\nlower level APIs:
\nFor each DjangoTemplates backend\nin the TEMPLATES setting, Django instantiates an\nEngine. DjangoTemplates\nwraps Engine and adapts it to the common template backend API.
The django.template.loader module provides functions such as\nget_template() for loading templates. They\nreturn a django.template.backends.django.Template which wraps the\nactual django.template.Template.
The Template obtained in the previous step has a\nrender() method which\nmarshals a context and possibly a request into a Context and\ndelegates the rendering to the underlying Template.
If you are using the DjangoTemplates\nbackend, this probably isn’t the documentation you’re looking for. An instance\nof the Engine class described below is accessible using the engine\nattribute of that backend and any attribute defaults mentioned below are\noverridden by what’s passed by\nDjangoTemplates.
When instantiating an Engine all arguments must be passed as keyword\narguments:
dirs is a list of directories where the engine should look for\ntemplate source files. It is used to configure\nfilesystem.Loader.
It defaults to an empty list.
\napp_dirs only affects the default value of loaders. See below.
It defaults to False.
autoescape controls whether HTML autoescaping is enabled.
It defaults to True.
context_processors is a list of dotted Python paths to callables\nthat are used to populate the context when a template is rendered with a\nrequest. These callables take a request object as their argument and\nreturn a dict of items to be merged into the context.
It defaults to an empty list.
\nSee RequestContext for more information.
debug is a boolean that turns on/off template debug mode. If it is\nTrue, the template engine will store additional debug information\nwhich can be used to display a detailed report for any exception raised\nduring template rendering.
It defaults to False.
loaders is a list of template loader classes, specified as strings.\nEach Loader class knows how to import templates from a particular\nsource. Optionally, a tuple can be used instead of a string. The first\nitem in the tuple should be the Loader class name, subsequent items\nare passed to the Loader during initialization.
It defaults to a list containing:
\n'django.template.loaders.filesystem.Loader'
'django.template.loaders.app_directories.Loader' if and only if\napp_dirs is True.
These loaders are then wrapped in\ndjango.template.loaders.cached.Loader.
See Loader types for details.
\nstring_if_invalid is the output, as a string, that the template\nsystem should use for invalid (e.g. misspelled) variables.
It defaults to the empty string.
\nSee How invalid variables are handled for details.
\nfile_charset is the charset used to read template files on disk.
It defaults to 'utf-8'.
'libraries': A dictionary of labels and dotted Python paths of\ntemplate tag modules to register with the template engine. This is used\nto add new libraries or provide alternate labels for existing ones. For\nexample:
Engine(\n libraries={\n "myapp_tags": "path.to.myapp.tags",\n "admin.urls": "django.contrib.admin.templatetags.admin_urls",\n },\n)\nLibraries can be loaded by passing the corresponding dictionary key to\nthe {% load %} tag.
'builtins': A list of dotted Python paths of template tag modules to\nadd to built-ins. For example:
Engine(\n builtins=["myapp.builtins"],\n)\nTags and filters from built-in libraries can be used without first\ncalling the {% load %} tag.
Returns the underlying Engine from the first configured\nDjangoTemplates engine. Raises\nImproperlyConfigured if no engines are\nconfigured.
It’s required for preserving APIs that rely on a globally available,\nimplicitly configured engine. Any other use is strongly discouraged.
\nCompiles the given template code and returns a Template object.
Loads a template with the given name, compiles it and returns a\nTemplate object.
Like get_template(), except it takes a list of names\nand returns the first template that was found.
The recommended way to create a Template is by calling the factory\nmethods of the Engine: get_template(),\nselect_template() and from_string().
In a Django project where the TEMPLATES setting defines a\nDjangoTemplates engine, it’s\npossible to instantiate a Template directly. If more than one\nDjangoTemplates engine is defined,\nthe first one will be used.
This class lives at django.template.Template. The constructor takes\none argument — the raw template code:
from django.template import Template\n\ntemplate = Template("My name is {{ my_name }}.")\nOnce you have a compiled Template object, you can render a context\nwith it. You can reuse the same template to render it several times with\ndifferent contexts.
The constructor of django.template.Context takes an optional argument —\na dictionary mapping variable names to variable values.
Three optional keyword arguments can also be specified:
\nautoescape controls whether HTML autoescaping is enabled.
It defaults to True.
use_l10n overrides whether values will be localized by default. If\nset to True numbers and dates will be formatted based on locale.
It defaults to None.
See Controlling localization in templates for details.
\nuse_tz overrides whether dates are converted to the local time when\nrendered in a template. If set to True all dates will be rendered\nusing the local timezone. This takes precedence over USE_TZ.
It defaults to None.
See Time zone aware output in templates for details.
\nFor example usage, see Playing with Context objects below.
\nCall the Template object’s render() method with a\nContext to “fill” the template:
>>> from django.template import Context, Template\n>>> template = Template("My name is {{ my_name }}.")\n\n>>> context = Context({"my_name": "Adrian"})\n>>> template.render(context)\n"My name is Adrian."\n\n>>> context = Context({"my_name": "Dolores"})\n>>> template.render(context)\n"My name is Dolores."\nVariable names must consist of any letter (A-Z), any digit (0-9), an underscore\n(but they must not start with an underscore) or a dot.
\nDots have a special meaning in template rendering. A dot in a variable name\nsignifies a lookup. Specifically, when the template system encounters a\ndot in a variable name, it tries the following lookups, in this order:
\nDictionary 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\ninterpreted as a literal string and not using the value of the variable “bar”,\nif one exists in the template context.
The template system uses the first lookup type that works. It’s short-circuit\nlogic. Here are a few examples:
\n>>> from django.template import Context, Template\n>>> t = Template("My name is {{ person.first_name }}.")\n>>> d = {"person": {"first_name": "Joe", "last_name": "Johnson"}}\n>>> t.render(Context(d))\n"My name is Joe."\n\n>>> class PersonClass:\n... pass\n...\n>>> p = PersonClass()\n>>> p.first_name = "Ron"\n>>> p.last_name = "Nasty"\n>>> t.render(Context({"person": p}))\n"My name is Ron."\n\n>>> t = Template("The first stooge in the list is {{ stooges.0 }}.")\n>>> c = Context({"stooges": ["Larry", "Curly", "Moe"]})\n>>> t.render(c)\n"The first stooge in the list is Larry."\nIf any part of the variable is callable, the template system will try calling\nit. Example:
\n>>> class PersonClass2:\n... def name(self):\n... return "Samantha"\n...\n>>> t = Template("My name is {{ person.name }}.")\n>>> t.render(Context({"person": PersonClass2}))\n"My name is Samantha."\nCallable variables are slightly more complex than variables which only require\nstraight lookups. Here are some things to keep in mind:
\nIf the variable raises an exception when called, the exception will be\npropagated, unless the exception has an attribute\nsilent_variable_failure whose value is True. If the exception\ndoes have a silent_variable_failure attribute whose value is\nTrue, the variable will render as the value of the engine’s\nstring_if_invalid configuration option (an empty string, by default).\nExample:
>>> t = Template("My name is {{ person.first_name }}.")\n>>> class PersonClass3:\n... def first_name(self):\n... raise AssertionError("foo")\n...\n>>> p = PersonClass3()\n>>> t.render(Context({"person": p}))\nTraceback (most recent call last):\n...\nAssertionError: foo\n\n>>> class SilentAssertionError(Exception):\n... silent_variable_failure = True\n...\n>>> class PersonClass4:\n... def first_name(self):\n... raise SilentAssertionError\n...\n>>> p = PersonClass4()\n>>> t.render(Context({"person": p}))\n"My name is ."\nNote that django.core.exceptions.ObjectDoesNotExist, which is the\nbase class for all Django database API DoesNotExist exceptions, has\nsilent_variable_failure = True. So if you’re using Django templates\nwith Django model objects, any DoesNotExist exception will fail\nsilently.
A variable can only be called if it has no required arguments. Otherwise,\nthe system will return the value of the engine’s string_if_invalid\noption.
There can be side effects when calling some variables, and it’d be either\nfoolish or a security hole to allow the template system to access them.
\nA good example is the delete() method on\neach Django model object. The template system shouldn’t be allowed to do\nsomething like this:
I will now delete this valuable data. {{ data.delete }}\nTo prevent this, set an alters_data attribute on the callable\nvariable. The template system won’t call a variable if it has\nalters_data=True set, and will instead replace the variable with\nstring_if_invalid, unconditionally. The\ndynamically-generated delete() and\nsave() methods on Django model objects get\nalters_data=True automatically. Example:
def sensitive_function(self):\n self.database_record.delete()\n\n\nsensitive_function.alters_data = True\nOccasionally you may want to turn off this feature for other reasons,\nand tell the template system to leave a variable uncalled no matter\nwhat. To do so, set a do_not_call_in_templates attribute on the\ncallable with the value True. The template system then will act as\nif your variable is not callable (allowing you to access attributes of\nthe callable, for example).
Generally, if a variable doesn’t exist, the template system inserts the value\nof the engine’s string_if_invalid configuration option, which is set to\n'' (the empty string) by default.
Filters that are applied to an invalid variable will only be applied if\nstring_if_invalid is set to '' (the empty string). If\nstring_if_invalid is set to any other value, variable filters will be\nignored.
This behavior is slightly different for the if, for and regroup\ntemplate tags. If an invalid variable is provided to one of these template\ntags, the variable will be interpreted as None. Filters are always\napplied to invalid variables within these template tags.
If string_if_invalid contains a '%s', the format marker will be\nreplaced with the name of the invalid variable.
Every context contains True, False and None. As you would expect,\nthese variables resolve to the corresponding Python objects.
Django’s template language has no way to escape the characters used for its own\nsyntax. For example, the templatetag tag is required if you need to\noutput character sequences like {% and %}.
A similar issue exists if you want to include these sequences in template\nfilter or tag arguments. For example, when parsing a block tag, Django’s\ntemplate parser looks for the first occurrence of %} after a {%. This\nprevents the use of "%}" as a string literal. For example, a\nTemplateSyntaxError will be raised for the following expressions:
{% include "template.html" tvar="Some string literal with %} in it." %}\n\n{% with tvar="Some string literal with %} in it." %}{% endwith %}\nThe same issue can be triggered by using a reserved sequence in filter\narguments:
\n{{ some.variable|default:"}}" }}\nIf you need to use strings with these sequences, store them in template\nvariables or use a custom template tag or filter to workaround the limitation.
\nContext objectsLink to this heading#Most of the time, you’ll instantiate Context objects by passing in a\nfully-populated dictionary to Context(). But you can add and delete items\nfrom a Context object once it’s been instantiated, too, using standard\ndictionary syntax:
>>> from django.template import Context\n>>> c = Context({"foo": "bar"})\n>>> c["foo"]\n'bar'\n>>> del c["foo"]\n>>> c["foo"]\nTraceback (most recent call last):\n...\nKeyError: 'foo'\n>>> c["newvariable"] = "hello"\n>>> c["newvariable"]\n'hello'\nReturns the value for key if key is in the context, else returns\notherwise.
If key is in the context, returns its value. Otherwise inserts key\nwith a value of default and returns default.
A Context object is a stack. That is, you can push() and pop() it.\nIf you pop() too much, it’ll raise\ndjango.template.ContextPopException:
>>> c = Context()\n>>> c["foo"] = "first level"\n>>> c.push()\n{}\n>>> c["foo"] = "second level"\n>>> c["foo"]\n'second level'\n>>> c.pop()\n{'foo': 'second level'}\n>>> c["foo"]\n'first level'\n>>> c["foo"] = "overwritten"\n>>> c["foo"]\n'overwritten'\n>>> c.pop()\nTraceback (most recent call last):\n...\nContextPopException\nYou can also use push() as a context manager to ensure a matching pop()\nis called.
>>> c = Context()\n>>> c["foo"] = "first level"\n>>> with c.push():\n... c["foo"] = "second level"\n... c["foo"]\n...\n'second level'\n>>> c["foo"]\n'first level'\nAll arguments passed to push() will be passed to the dict constructor\nused to build the new context level.
>>> c = Context()\n>>> c["foo"] = "first level"\n>>> with c.push(foo="second level"):\n... c["foo"]\n...\n'second level'\n>>> c["foo"]\n'first level'\nIn addition to push() and pop(), the Context\nobject also defines an update() method. This works like push()\nbut takes a dictionary as an argument and pushes that dictionary onto\nthe stack instead of an empty one.
>>> c = Context()\n>>> c["foo"] = "first level"\n>>> c.update({"foo": "updated"})\n{'foo': 'updated'}\n>>> c["foo"]\n'updated'\n>>> c.pop()\n{'foo': 'updated'}\n>>> c["foo"]\n'first level'\nLike push(), you can use update() as a context manager to ensure a\nmatching pop() is called.
>>> c = Context()\n>>> c["foo"] = "first level"\n>>> with c.update({"foo": "second level"}):\n... c["foo"]\n...\n'second level'\n>>> c["foo"]\n'first level'\nUsing a Context as a stack comes in handy in some custom template\ntags.
Using flatten() method you can get whole Context stack as one\ndictionary including builtin variables.
>>> c = Context()\n>>> c["foo"] = "first level"\n>>> c.update({"bar": "second level"})\n{'bar': 'second level'}\n>>> c.flatten()\n{'True': True, 'None': None, 'foo': 'first level', 'False': False, 'bar': 'second level'}\nA flatten() method is also internally used to make Context objects\ncomparable.
>>> c1 = Context()\n>>> c1["foo"] = "first level"\n>>> c1["bar"] = "second level"\n>>> c2 = Context()\n>>> c2.update({"bar": "second level", "foo": "first level"})\n{'foo': 'first level', 'bar': 'second level'}\n>>> c1 == c2\nTrue\nResult from flatten() can be useful in unit tests to compare Context\nagainst dict:
class ContextTest(unittest.TestCase):\n def test_against_dictionary(self):\n c1 = Context()\n c1["update"] = "value"\n self.assertEqual(\n c1.flatten(),\n {\n "True": True,\n "None": None,\n "False": False,\n "update": "value",\n },\n )\nRequestContextLink to this heading#Django comes with a special Context class,\ndjango.template.RequestContext, that acts slightly differently from the\nnormal django.template.Context. The first difference is that it takes an\nHttpRequest as its first argument. For example:
c = RequestContext(\n request,\n {\n "foo": "bar",\n },\n)\nThe second difference is that it automatically populates the context with a\nfew variables, according to the engine’s context_processors configuration\noption.
The context_processors option is a list of callables – called context\nprocessors – that take a request object as their argument and return a\ndictionary of items to be merged into the context. In the default generated\nsettings file, the default template engine contains the following context\nprocessors:
[\n "django.template.context_processors.request",\n "django.contrib.auth.context_processors.auth",\n "django.contrib.messages.context_processors.messages",\n]\nIn addition to these, RequestContext always enables\n'django.template.context_processors.csrf'. This is a security related\ncontext processor required by the admin and other contrib apps, and, in case\nof accidental misconfiguration, it is deliberately hardcoded in and cannot be\nturned off in the context_processors option.
Each processor is applied in order. That means, if one processor adds a\nvariable to the context and a second processor adds a variable with the same\nname, the second will override the first. The default processors are explained\nbelow.
\n\nAlso, you can give RequestContext a list of additional processors,\nusing the optional, third positional argument, processors. In this\nexample, the RequestContext instance gets an ip_address variable:
from django.http import HttpResponse\nfrom django.template import RequestContext, Template\n\n\ndef ip_address_processor(request):\n return {"ip_address": request.META["REMOTE_ADDR"]}\n\n\ndef client_ip_view(request):\n template = Template("{{ title }}: {{ ip_address }}")\n context = RequestContext(\n request,\n {\n "title": "Your IP Address",\n },\n [ip_address_processor],\n )\n return HttpResponse(template.render(context))\nHere’s what each of the built-in processors does:
\ndjango.contrib.auth.context_processors.authLink to this heading#If this processor is enabled, every RequestContext will contain these\nvariables:
user – An auth.User instance representing the currently\nlogged-in user (or an AnonymousUser instance, if the client isn’t\nlogged in).
perms – An instance of\ndjango.contrib.auth.context_processors.PermWrapper, representing the\npermissions that the currently logged-in user has.
django.template.context_processors.debugLink to this heading#If this processor is enabled, every RequestContext will contain these two\nvariables – but only if your DEBUG setting is set to True and\nthe request’s IP address (request.META['REMOTE_ADDR']) is in the\nINTERNAL_IPS setting:
debug – True. You can use this in templates to test whether\nyou’re in DEBUG mode.
sql_queries – A list of {'sql': ..., 'time': ...} dictionaries,\nrepresenting every SQL query that has happened so far during the request\nand how long it took. The list is in order by database alias and then by\nquery. It’s lazily generated on access.
django.template.context_processors.i18nLink to this heading#If this processor is enabled, every RequestContext will contain these\nvariables:
LANGUAGES – The value of the LANGUAGES setting.
LANGUAGE_BIDI – True if the current language is a right-to-left\nlanguage, e.g. Hebrew, Arabic. False if it’s a left-to-right language,\ne.g. English, French, German.
LANGUAGE_CODE – request.LANGUAGE_CODE, if it exists. Otherwise,\nthe value of the LANGUAGE_CODE setting.
See i18n template tags for template tags that\ngenerate the same values.
\ndjango.template.context_processors.mediaLink to this heading#If this processor is enabled, every RequestContext will contain a variable\nMEDIA_URL, providing the value of the MEDIA_URL setting.
django.template.context_processors.staticLink to this heading#If this processor is enabled, every RequestContext will contain a variable\nSTATIC_URL, providing the value of the STATIC_URL setting.
django.template.context_processors.csrfLink to this heading#This processor adds a token that is needed by the csrf_token template\ntag for protection against Cross Site Request Forgeries.
This is always enabled by RequestContext and cannot\nbe disabled. You do not need to include it within context_processors.
django.template.context_processors.cspLink to this heading#If this processor is enabled, every RequestContext will contain a variable\ncsp_nonce, providing a securely generated, request-specific nonce suitable\nfor use under a Content Security Policy. See CSP nonce usage\nfor details.
django.template.context_processors.requestLink to this heading#If this processor is enabled, every RequestContext will contain a variable\nrequest, which is the current HttpRequest.
django.template.context_processors.tzLink to this heading#If this processor is enabled, every RequestContext will contain a variable\nTIME_ZONE, providing the name of the currently active time zone.
django.contrib.messages.context_processors.messagesLink to this heading#If this processor is enabled, every RequestContext will contain these two\nvariables:
messages – A list of messages (as strings) that have been set\nvia the messages framework.
DEFAULT_MESSAGE_LEVELS – A mapping of the message level names to\ntheir numeric value.
A context processor has a simple interface: It’s a Python function that takes\none argument, an HttpRequest object, and returns a\ndictionary that gets added to the template context.
For example, to add the DEFAULT_FROM_EMAIL setting to every\ncontext:
from django.conf import settings\n\n\ndef from_email(request):\n return {\n "DEFAULT_FROM_EMAIL": settings.DEFAULT_FROM_EMAIL,\n }\nCustom context processors can live anywhere in your code base. All Django\ncares about is that your custom context processors are pointed to by the\n'context_processors' option in your TEMPLATES setting — or the\ncontext_processors argument of Engine if you’re\nusing it directly.
Generally, you’ll store templates in files on your filesystem rather than\nusing the low-level Template API yourself. Save\ntemplates in a directory specified as a template directory.
Django searches for template directories in a number of places, depending on\nyour template loading settings (see “Loader types” below), but the most basic\nway of specifying template directories is by using the DIRS option.
DIRS optionLink to this heading#Tell Django what your template directories are by using the DIRS option in the TEMPLATES setting in your settings\nfile — or the dirs argument of Engine. This\nshould be set to a list of strings that contain full paths to your template\ndirectories:
TEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "DIRS": [\n "/home/html/templates/lawrence.com",\n "/home/html/templates/default",\n ],\n },\n]\nYour templates can go anywhere you want, as long as the directories and\ntemplates are readable by the web server. They can have any extension you want,\nsuch 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.
\nBy default, Django uses a filesystem-based template loader, but Django comes\nwith a few other template loaders, which know how to load templates from other\nsources.
\nSome of these other loaders are disabled by default, but you can activate them\nby adding a 'loaders' option to your DjangoTemplates backend in the\nTEMPLATES setting or passing a loaders argument to\nEngine. loaders should be a list of strings or\ntuples, where each represents a template loader class. Here are the template\nloaders that come with Django:
django.template.loaders.filesystem.Loader
Loads templates from the filesystem, according to\nDIRS.
This loader is enabled by default. However it won’t find any templates\nuntil you set DIRS to a non-empty list:
TEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "DIRS": [BASE_DIR / "templates"],\n }\n]\nYou can also override 'DIRS' and specify specific directories for a\nparticular filesystem loader:
TEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "OPTIONS": {\n "loaders": [\n (\n "django.template.loaders.filesystem.Loader",\n [BASE_DIR / "templates"],\n ),\n ],\n },\n }\n]\ndjango.template.loaders.app_directories.Loader
Loads templates from Django apps on the filesystem. For each app in\nINSTALLED_APPS, the loader looks for a templates\nsubdirectory. If the directory exists, Django looks for templates in there.
This means you can store templates with your individual apps. This also\nhelps to distribute Django apps with default templates.
\nFor example, for this setting:
\nINSTALLED_APPS = ["myproject.polls", "myproject.music"]\n…then get_template('foo.html') will look for foo.html in these\ndirectories, in this order:
/path/to/myproject/polls/templates/
/path/to/myproject/music/templates/
… and will use the one it finds first.
\nThe order of INSTALLED_APPS is significant! For example, if you\nwant to customize the Django admin, you might choose to override the\nstandard admin/base_site.html template, from django.contrib.admin,\nwith your own admin/base_site.html in myproject.polls. You must\nthen make sure that your myproject.polls comes before\ndjango.contrib.admin in INSTALLED_APPS, otherwise\ndjango.contrib.admin’s will be loaded first and yours will be ignored.
Note that the loader performs an optimization when it first runs:\nit caches a list of which INSTALLED_APPS packages have a\ntemplates subdirectory.
You can enable this loader by setting APP_DIRS to True:
TEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "APP_DIRS": True,\n }\n]\ndjango.template.loaders.cached.Loader
While the Django template system is quite fast, if it needs to read and\ncompile your templates every time they’re rendered, the overhead from that\ncan add up.
\nYou configure the cached template loader with a list of other loaders that\nit should wrap. The wrapped loaders are used to locate unknown templates\nwhen they’re first encountered. The cached loader then stores the compiled\nTemplate in memory. The cached Template instance is returned for\nsubsequent requests to load the same template.
This loader is automatically enabled if OPTIONS['loaders'] isn’t specified.
You can manually specify template caching with some custom template loaders\nusing settings like this:
\nTEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "DIRS": [BASE_DIR / "templates"],\n "OPTIONS": {\n "loaders": [\n (\n "django.template.loaders.cached.Loader",\n [\n "django.template.loaders.filesystem.Loader",\n "django.template.loaders.app_directories.Loader",\n "path.to.custom.Loader",\n ],\n ),\n ],\n },\n }\n]\ndjango.template.loaders.locmem.Loader
Loads templates from a Python dictionary. This is useful for testing.
\nThis loader takes a dictionary of templates as its first argument:
\nTEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "OPTIONS": {\n "loaders": [\n (\n "django.template.loaders.locmem.Loader",\n {\n "index.html": "content here",\n },\n ),\n ],\n },\n }\n]\nThis loader is disabled by default.
\nDjango uses the template loaders in order according to the 'loaders'\noption. It uses each loader until a loader finds a match.
It’s possible to load templates from additional sources using custom template\nloaders. Custom Loader classes should inherit from\ndjango.template.loaders.base.Loader and define the get_contents() and\nget_template_sources() methods.
Loads templates from a given source, such as the filesystem or a database.
\nA method that takes a template_name and yields\nOrigin instances for each possible\nsource.
For example, the filesystem loader may receive 'index.html' as a\ntemplate_name argument. This method would yield origins for the\nfull path of index.html as it appears in each template directory\nthe loader looks at.
The method doesn’t need to verify that the template exists at a given\npath, but it should ensure the path is valid. For instance, the\nfilesystem loader makes sure the path lies under a valid template\ndirectory.
\nReturns the contents for a template given a\nOrigin instance.
This is where a filesystem loader would read contents from the\nfilesystem, or a database loader would read from the database. If a\nmatching template doesn’t exist, this should raise a\nTemplateDoesNotExist error.
Returns a Template object for a given template_name by looping\nthrough results from get_template_sources() and calling\nget_contents(). This returns the first matching template. If no\ntemplate is found, TemplateDoesNotExist is\nraised.
The optional skip argument is a list of origins to ignore when\nextending templates. This allow templates to extend other templates of\nthe same name. It also used to avoid recursion errors.
In general, it is enough to define get_template_sources() and\nget_contents() for custom template loaders. get_template()\nwill usually not need to be overridden.
Templates have an origin containing attributes depending on the source\nthey are loaded from.
The path to the template as returned by the template loader.\nFor loaders that read from the file system, this is the full\npath to the template.
\nIf the template is instantiated directly rather than through a\ntemplate loader, this is a string value of <unknown_source>.
The relative path to the template as passed into the\ntemplate loader.
\nIf the template is instantiated directly rather than through a\ntemplate loader, this is None.
The template loader instance that constructed this Origin.
If the template is instantiated directly rather than through a\ntemplate loader, this is None.
django.template.loaders.cached.Loader requires all of its\nwrapped loaders to set this attribute, typically by instantiating\nthe Origin with loader=self.