<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
	
<!-- Mirrored from www.djangoproject.com/documentation/templates_python/ by HTTrack Website Copier/3.x [XR&CO'2005], Fri, 25 Nov 2005 13:28:51 GMT -->
<!-- Added by HTTrack --><meta http-equiv="content-type" content="text/html;charset=utf-8"><!-- /Added by HTTrack -->
<head>
		<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
		<meta http-equiv="Content-Language" content="en-us" />

		<title>Django | Documentation | The template language: For Python programmers</title>

		<meta name="ROBOTS" content="ALL" />
		<meta http-equiv="imagetoolbar" content="no" />
		<meta name="MSSmartTagsPreventParsing" content="true" />
		<meta name="Copyright" content="This site's design and contents Copyright (c) 2005  Lawrence Journal-World." />

		<meta name="keywords" content="Python, Django, framework, open-source" />
		<meta name="description" content="Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design." />

		<link href="../../../media.djangoproject.com/css/base.css" rel="stylesheet" type="text/css" media="screen" />
		<link href="../../../media.djangoproject.com/css/print.css" rel="stylesheet" type="text/css" media="print" />
      
	</head>

	<body id="documentation">

	<div id="container">
		<div id="header">
			<h1 id="logo"><a href="http://www.djangoproject.com/"><img src="../../../media.djangoproject.com/img/site/hdr_logo.gif" alt="Django" /></a></h1>
			<ul id="nav-global">
				<li id="nav-homepage"><a href="http://www.djangoproject.com/">Home</a></li>
				<li id="nav-download"><a href="http://www.djangoproject.com/download/">Download</a></li>
				<li id="nav-documentation"><a href="../index.html">Documentation</a></li>
				<li id="nav-weblog"><a href="http://www.djangoproject.com/weblog/">Weblog</a></li>
				<li id="nav-community"><a href="http://www.djangoproject.com/community/">Community</a></li>
				<li id="nav-code"><a href="http://code.djangoproject.com/">Code</a></li>
			</ul>
		</div>
		<!-- END Header -->
		<div id="billboard"><h2><a href="../index.html">Django documentation</a></h2></div>
		<div id="columnwrap">
			
		<div id="content-main">
		
<div class="document" id="the-django-template-language-for-python-programmers">
<h1 class="title">The Django template language: For Python programmers</h1>
<p>This document explains the Django template system from a technical
perspective -- how it works and how to extend it. If you're just looking for
reference on the language syntax, see
<a class="reference" href="../templates/index.html">The Django template language: For template authors</a>.</p>
<div class="section" id="basics">
<h2>Basics</h2>
<p>A <strong>template</strong> is a text document, or a normal Python string, that is marked-up
using the Django template language. A template can contain <strong>block tags</strong> or
<strong>variables</strong>.</p>
<p>A <strong>block tag</strong> is a symbol within a template that does something.</p>
<p>This definition is deliberately vague. For example, a block tag can output
content, serve as a control structure (an &quot;if&quot; statement or &quot;for&quot; loop), grab
content from a database or enable access to other template tags.</p>
<p>Block tags are surrounded by <tt class="docutils literal"><span class="pre">&quot;{%&quot;</span></tt> and <tt class="docutils literal"><span class="pre">&quot;%}&quot;</span></tt>.</p>
<p>Example template with block tags:</p>
<pre class="literal-block">
{% if is_logged_in %}Thanks for logging in!{% else %}Please log in.{% endif %}
</pre>
<p>A <strong>variable</strong> is a symbol within a template that outputs a value.</p>
<p>Variable tags are surrounded by <tt class="docutils literal"><span class="pre">&quot;{{&quot;</span></tt> and <tt class="docutils literal"><span class="pre">&quot;}}&quot;</span></tt>.</p>
<p>Example template with variables:</p>
<pre class="literal-block">
My first name is {{ first_name }}. My last name is {{ last_name }}.
</pre>
<p>A <strong>context</strong> is a &quot;variable name&quot; -&gt; &quot;variable value&quot; mapping that is passed
to a template.</p>
<p>A template <strong>renders</strong> a context by replacing the variable &quot;holes&quot; with values
from the context and executing all block tags.</p>
</div>
<div class="section" id="using-the-template-system">
<h2>Using the template system</h2>
<p>Using the template system in Python is a two-step process:</p>
<blockquote>
<ul class="simple">
<li>First, you compile the raw template code into a <tt class="docutils literal"><span class="pre">Template</span></tt> object.</li>
<li>Then, you call the <tt class="docutils literal"><span class="pre">render()</span></tt> method of the <tt class="docutils literal"><span class="pre">Template</span></tt> object with a
given context.</li>
</ul>
</blockquote>
<div class="section" id="compiling-a-string">
<h3>Compiling a string</h3>
<p>The easiest way to create a <tt class="docutils literal"><span class="pre">Template</span></tt> object is by instantiating it
directly. The class lives at <tt class="docutils literal"><span class="pre">django.core.template.Template</span></tt>. The constructor
takes one argument -- the raw template code:</p>
<pre class="literal-block">
&gt;&gt;&gt; from django.core.template import Template
&gt;&gt;&gt; t = Template(&quot;My name is {{ my_name }}.&quot;)
&gt;&gt;&gt; print t
&lt;django.core.template.Template instance&gt;
</pre>
<div class="admonition-behind-the-scenes admonition">
<p class="first admonition-title">Behind the scenes</p>
<p>The system only parses your raw template code once -- when you create the
<tt class="docutils literal"><span class="pre">Template</span></tt> object. From then on, it's stored internally as a &quot;node&quot;
structure for performance.</p>
<p class="last">Even the parsing itself is quite fast. Most of the parsing happens via a
single call to a single, short, regular expression.</p>
</div>
</div>
<div class="section" id="rendering-a-context">
<h3>Rendering a context</h3>
<p>Once you have a compiled <tt class="docutils literal"><span class="pre">Template</span></tt> object, you can render a context -- or
multiple contexts -- with it. The <tt class="docutils literal"><span class="pre">Context</span></tt> class lives at
<tt class="docutils literal"><span class="pre">django.core.template.Context</span></tt>, and the constructor takes one (optional)
argument: a dictionary mapping variable names to variable values. Call the
<tt class="docutils literal"><span class="pre">Template</span></tt> object's <tt class="docutils literal"><span class="pre">render()</span></tt> method with the context to &quot;fill&quot; the
template:</p>
<pre class="literal-block">
&gt;&gt;&gt; from django.core.template import Context, Template
&gt;&gt;&gt; t = Template(&quot;My name is {{ my_name }}.&quot;)

&gt;&gt;&gt; c = Context({&quot;my_name&quot;: &quot;Adrian&quot;})
&gt;&gt;&gt; t.render(c)
&quot;My name is Adrian.&quot;

&gt;&gt;&gt; c = Context({&quot;my_name&quot;: &quot;Dolores&quot;})
&gt;&gt;&gt; t.render(c)
&quot;My name is Dolores.&quot;
</pre>
<p>Variable names must consist of any letter (A-Z), any digit (0-9), an underscore
or a dot.</p>
<p>Dots have a special meaning in template rendering. A dot in a variable name
signifies <strong>lookup</strong>. Specifically, when the template system encounters a dot
in a variable name, it tries the following lookups, in this order:</p>
<blockquote>
<ul class="simple">
<li>Dictionary lookup. Example: <tt class="docutils literal"><span class="pre">foo[&quot;bar&quot;]</span></tt></li>
<li>Attribute lookup. Example: <tt class="docutils literal"><span class="pre">foo.bar</span></tt></li>
<li>Method call. Example: <tt class="docutils literal"><span class="pre">foo.bar()</span></tt></li>
<li>List-index lookup. Example: <tt class="docutils literal"><span class="pre">foo[bar]</span></tt></li>
</ul>
</blockquote>
<p>The template system uses the first lookup type that works. It's short-circuit
logic.</p>
<p>Here are a few examples:</p>
<pre class="literal-block">
&gt;&gt;&gt; from django.core.template import Context, Template
&gt;&gt;&gt; t = Template(&quot;My name is {{ person.first_name }}.&quot;)
&gt;&gt;&gt; d = {&quot;person&quot;: {&quot;first_name&quot;: &quot;Joe&quot;, &quot;last_name&quot;: &quot;Johnson&quot;}}
&gt;&gt;&gt; t.render(Context(d))
&quot;My name is Joe.&quot;

&gt;&gt;&gt; class PersonClass: pass
&gt;&gt;&gt; p = PersonClass()
&gt;&gt;&gt; p.first_name = &quot;Ron&quot;
&gt;&gt;&gt; p.last_name = &quot;Nasty&quot;
&gt;&gt;&gt; t.render(Context({&quot;person&quot;: p}))
&quot;My name is Ron.&quot;

&gt;&gt;&gt; class PersonClass2:
...     def first_name(self):
...         return &quot;Samantha&quot;
&gt;&gt;&gt; p = PersonClass2()
&gt;&gt;&gt; t.render(Context({&quot;person&quot;: p}))
&quot;My name is Samantha.&quot;

&gt;&gt;&gt; t = Template(&quot;The first stooge in the list is {{ stooges.0 }}.&quot;)
&gt;&gt;&gt; c = Context({&quot;stooges&quot;: [&quot;Larry&quot;, &quot;Curly&quot;, &quot;Moe&quot;]})
&gt;&gt;&gt; t.render(c)
&quot;The first stooge in the list is Larry.&quot;
</pre>
<p>If a variable doesn't exist, the template system fails silently. The variable
is replaced with an empty string:</p>
<pre class="literal-block">
&gt;&gt;&gt; t = Template(&quot;My name is {{ my_name }}.&quot;)
&gt;&gt;&gt; c = Context({&quot;foo&quot;: &quot;bar&quot;})
&gt;&gt;&gt; t.render(c)
&quot;My name is .&quot;
</pre>
<p>Method lookups are slightly more complex than the other lookup types. Here are
some things to keep in mind:</p>
<blockquote>
<ul>
<li><p class="first">If, during the method lookup, a method raises an exception, the exception
will be propagated, unless the exception subclasses
<tt class="docutils literal"><span class="pre">django.core.template.SilentVariableFailure</span></tt>. If the exception
subclasses <tt class="docutils literal"><span class="pre">SilentVariableFailure</span></tt>, the variable will render as an
empty string. Example:</p>
<pre class="literal-block">
&gt;&gt;&gt; t = Template(&quot;My name is {{ person.first_name }}.&quot;)
&gt;&gt;&gt; class PersonClass3:
...     def first_name(self):
...         raise AssertionError, &quot;foo&quot;
&gt;&gt;&gt; p = PersonClass3()
&gt;&gt;&gt; t.render(Context({&quot;person&quot;: p}))
Traceback (most recent call last):
...
AssertionError: foo

&gt;&gt;&gt; from django.core.template import SilentVariableFailure
&gt;&gt;&gt; class SilentAssertionError(SilentVariableFailure): pass
&gt;&gt;&gt; class PersonClass4:
...     def first_name(self):
...         raise SilentAssertionError, &quot;foo&quot;
&gt;&gt;&gt; p = PersonClass4()
&gt;&gt;&gt; t.render(Context({&quot;person&quot;: p}))
&quot;My name is .&quot;
</pre>
</li>
<li><p class="first">A method call will only work if the method has no required arguments.
Otherwise, the system will move to the next lookup type (list-index
lookup).</p>
</li>
<li><p class="first">Obviously, some methods have side effects, and it'd be either foolish or
a security hole to allow the template system to access them.</p>
<p>A good example is the <tt class="docutils literal"><span class="pre">delete()</span></tt> method on each Django model object.
The template system shouldn't be allowed to do something like this:</p>
<pre class="literal-block">
I will now delete this valuable data. {{ data.delete }}
</pre>
<p>To prevent this, set a function attribute <tt class="docutils literal"><span class="pre">alters_data</span></tt> on the method.
The template system won't execute a method if the method has
<tt class="docutils literal"><span class="pre">alters_data=True</span></tt> set. The dynamically-generated <tt class="docutils literal"><span class="pre">delete()</span></tt> and
<tt class="docutils literal"><span class="pre">save()</span></tt> methods on Django model objects get <tt class="docutils literal"><span class="pre">alters_data=True</span></tt>
automatically. Example:</p>
<pre class="literal-block">
def sensitive_function(self):
    self.database_record.delete()
sensitive_function.alters_data = True
</pre>
</li>
</ul>
</blockquote>
</div>
<div class="section" id="playing-with-context-objects">
<h3>Playing with Context objects</h3>
<p>Most of the time, you'll instantiate <tt class="docutils literal"><span class="pre">Context</span></tt> objects by passing in a
fully-populated dictionary to <tt class="docutils literal"><span class="pre">Context()</span></tt>. But you can add and delete items
from a <tt class="docutils literal"><span class="pre">Context</span></tt> object once it's been instantiated, too, using standard
dictionary syntax:</p>
<pre class="literal-block">
&gt;&gt;&gt; c = Context({&quot;foo&quot;: &quot;bar&quot;})
&gt;&gt;&gt; c['foo']
'bar'
&gt;&gt;&gt; del c['foo']
&gt;&gt;&gt; c['foo']
''
&gt;&gt;&gt; c['newvariable'] = 'hello'
&gt;&gt;&gt; c['newvariable']
'hello'
</pre>
<p>A <tt class="docutils literal"><span class="pre">Context</span></tt> object is a stack. That is, you can <tt class="docutils literal"><span class="pre">push()</span></tt> and <tt class="docutils literal"><span class="pre">pop()</span></tt> it.
If you <tt class="docutils literal"><span class="pre">pop()</span></tt> too much, it'll raise
<tt class="docutils literal"><span class="pre">django.core.template.ContextPopException</span></tt>:</p>
<pre class="literal-block">
&gt;&gt;&gt; c = Context()
&gt;&gt;&gt; c['foo'] = 'first level'
&gt;&gt;&gt; c.push()
&gt;&gt;&gt; c['foo'] = 'second level'
&gt;&gt;&gt; c['foo']
'second level'
&gt;&gt;&gt; c.pop()
&gt;&gt;&gt; c['foo']
'first level'
&gt;&gt;&gt; c['foo'] = 'overwritten'
&gt;&gt;&gt; c['foo']
'overwritten'
&gt;&gt;&gt; c.pop()
Traceback (most recent call last):
...
django.core.template.ContextPopException
</pre>
<p>Using a <tt class="docutils literal"><span class="pre">Context</span></tt> as a stack comes in handy in some custom template tags, as
you'll see below.</p>
</div>
<div class="section" id="subclassing-context-djangocontext">
<h3>Subclassing Context: DjangoContext</h3>
<p>Django comes with a special <tt class="docutils literal"><span class="pre">Context</span></tt> class,
<tt class="docutils literal"><span class="pre">django.core.extensions.DjangoContext</span></tt>, that acts slightly differently than
the normal <tt class="docutils literal"><span class="pre">django.core.template.Context</span></tt>. It takes an <tt class="docutils literal"><span class="pre">HttpRequest</span></tt> object
as its first argument, and it automatically populates the context with a few
variables:</p>
<blockquote>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">user</span></tt> -- An <tt class="docutils literal"><span class="pre">auth.User</span></tt> instance representing the currently
logged-in user (or an <tt class="docutils literal"><span class="pre">AnonymousUser</span></tt> instance, if the client isn't
logged in). See the <cite>user authentication docs</cite>.</li>
<li><tt class="docutils literal"><span class="pre">messages</span></tt> -- A list of <tt class="docutils literal"><span class="pre">auth.Message</span></tt> objects for the currently
logged-in user.</li>
<li><tt class="docutils literal"><span class="pre">perms</span></tt> -- An instance of <tt class="docutils literal"><span class="pre">django.core.extensions.PermWrapper</span></tt>,
representing the permissions that the currently logged-in user has. See
the <a class="reference" href="../models/authentication/index.html#permissions">permissions docs</a>.</li>
</ul>
</blockquote>
<p>Also, if your <tt class="docutils literal"><span class="pre">DEBUG</span></tt> setting is set to <tt class="docutils literal"><span class="pre">True</span></tt>, every <tt class="docutils literal"><span class="pre">DjangoContext</span></tt>
instance has the following two extra variables:</p>
<blockquote>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">debug</span></tt> -- <tt class="docutils literal"><span class="pre">True</span></tt>. You can use this in templates to test whether
you're in <tt class="docutils literal"><span class="pre">DEBUG</span></tt> mode.</li>
<li><tt class="docutils literal"><span class="pre">sql_queries</span></tt> -- A list of <tt class="docutils literal"><span class="pre">{'sql':</span> <span class="pre">...,</span> <span class="pre">'time':</span> <span class="pre">...}</span></tt> dictionaries,
representing every SQL query that has happened so far during the request
and how long it took. The list is in order by query.</li>
</ul>
</blockquote>
<p>Feel free to subclass <tt class="docutils literal"><span class="pre">Context</span></tt> yourself if you find yourself wanting to give
each template something &quot;automatically.&quot; For instance, if you want to give
every template automatic access to the current time, use something like this:</p>
<pre class="literal-block">
from django.core.template import Context
import datetime
class TimeContext(Context):
    def __init__(self, *args, **kwargs):
        Context.__init__(self, *args, **kwargs)
        self['current_time'] = datetime.datetime.now()
</pre>
<p>This technique has two caveats:</p>
<blockquote>
<ul class="simple">
<li>You'll have to remember to use <tt class="docutils literal"><span class="pre">TimeContext</span></tt> instead of <tt class="docutils literal"><span class="pre">Context</span></tt> in
your template-loading code.</li>
<li>You'll have to be careful not to set the variable <tt class="docutils literal"><span class="pre">current_time</span></tt> when
you populate this context. If you do, you'll override the other one.</li>
</ul>
</blockquote>
</div>
<div class="section" id="loading-templates">
<h3>Loading templates</h3>
<p>Generally, you'll store templates in files on your filesystem rather than using
the low-level <tt class="docutils literal"><span class="pre">Template</span></tt> API yourself. Save templates in a file with an
&quot;.html&quot; extension in a directory specified as a <strong>template directory</strong>.</p>
<p>If you don't like the requirement that templates have an &quot;.html&quot; extension,
change your <tt class="docutils literal"><span class="pre">TEMPLATE_FILE_EXTENSION</span></tt> setting. It's set to <tt class="docutils literal"><span class="pre">&quot;.html&quot;</span></tt> by
default.</p>
<p>Also, the .html extension doesn't mean templates can contain only HTML. They
can contain whatever textual content you want.</p>
<div class="section" id="the-template-dirs-setting">
<h4>The TEMPLATE_DIRS setting</h4>
<p>Tell Django what your template directories are by using the <tt class="docutils literal"><span class="pre">TEMPLATE_DIRS</span></tt>
setting in your settings file. This should be set to a list or tuple of strings
that contain full paths to your template directory(ies). Example:</p>
<pre class="literal-block">
TEMPLATE_DIRS = (
    &quot;/home/html/templates/lawrence.com&quot;,
    &quot;/home/html/templates/default&quot;,
)
</pre>
</div>
<div class="section" id="the-python-api">
<h4>The Python API</h4>
<p>Django has two ways to load templates from files:</p>
<dl class="docutils">
<dt><tt class="docutils literal"><span class="pre">django.core.template.loader.get_template(template_name)</span></tt></dt>
<dd><tt class="docutils literal"><span class="pre">get_template</span></tt> returns the compiled template (a <tt class="docutils literal"><span class="pre">Template</span></tt> object) for
the template with the given name. If the template doesn't exist, it raises
<tt class="docutils literal"><span class="pre">django.core.template.TemplateDoesNotExist</span></tt>.</dd>
<dt><tt class="docutils literal"><span class="pre">django.core.template.loader.select_template(template_name_list)</span></tt></dt>
<dd><tt class="docutils literal"><span class="pre">select_template</span></tt> is just like <tt class="docutils literal"><span class="pre">get_template</span></tt>, except it takes a list
of template names. Of the list, it returns the first template that exists.</dd>
</dl>
<p>For example, if you call <tt class="docutils literal"><span class="pre">get_template(&quot;story_detail&quot;)</span></tt> and have the above
<tt class="docutils literal"><span class="pre">TEMPLATE_DIRS</span></tt> setting, here are the files Django will look for, in order:</p>
<blockquote>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">/home/html/templates/lawrence.com/story_detail.html</span></tt></li>
<li><tt class="docutils literal"><span class="pre">/home/html/templates/default/story_detail.html</span></tt></li>
</ul>
</blockquote>
<p>If you call <tt class="docutils literal"><span class="pre">select_template([&quot;story_253_detail&quot;,</span> <span class="pre">&quot;story_detail&quot;])</span></tt>, here's
what Django will look for:</p>
<blockquote>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">/home/html/templates/lawrence.com/story_253_detail.html</span></tt></li>
<li><tt class="docutils literal"><span class="pre">/home/html/templates/default/story_253_detail.html</span></tt></li>
<li><tt class="docutils literal"><span class="pre">/home/html/templates/lawrence.com/story_detail.html</span></tt></li>
<li><tt class="docutils literal"><span class="pre">/home/html/templates/default/story_detail.html</span></tt></li>
</ul>
</blockquote>
<p>When Django finds a template that exists, it stops looking.</p>
<div class="admonition-tip admonition">
<p class="first admonition-title">Tip</p>
<p class="last">You can use <tt class="docutils literal"><span class="pre">select_template</span></tt> for super-flexible &quot;templatability.&quot; For
example, if you've written a news story and want some stories to have
custom templates, use something like
<tt class="docutils literal"><span class="pre">select_template([&quot;story_%s_detail&quot;</span> <span class="pre">%</span> <span class="pre">story.id,</span> <span class="pre">&quot;story_detail&quot;])</span></tt>.
That'll allow you to use a custom template for an individual story, with a
fallback template for stories that don't have custom templates.</p>
</div>
</div>
<div class="section" id="using-subdirectories">
<h4>Using subdirectories</h4>
<p>It's possible -- and preferable -- to organize templates in subdirectories of
the template directory. The convention is to make a subdirectory for each
Django app, with subdirectories within those subdirectories as needed.</p>
<p>Do this for your own sanity. Storing all templates in the root level of a
single directory gets messy.</p>
<p>To load a template that's within a subdirectory, just use a slash, like so:</p>
<pre class="literal-block">
get_template(&quot;news/story_detail&quot;)
</pre>
</div>
<div class="section" id="loader-types">
<h4>Loader types</h4>
<p>By default, Django uses a filesystem-based template loader, but Django comes
with a few other template loaders. They're disabled by default, but you can
activate them by editing your <tt class="docutils literal"><span class="pre">TEMPLATE_LOADERS</span></tt> setting.
<tt class="docutils literal"><span class="pre">TEMPLATE_LOADERS</span></tt> should be a tuple of strings, where each string represents
a template loader. Here are the built-in template loaders:</p>
<dl class="docutils">
<dt><tt class="docutils literal"><span class="pre">django.core.template.loaders.filesystem.load_template_source</span></tt></dt>
<dd>Loads templates from the filesystem, according to <tt class="docutils literal"><span class="pre">TEMPLATE_DIRS</span></tt>.</dd>
<dt><tt class="docutils literal"><span class="pre">django.core.template.loaders.app_directories.load_template_source</span></tt></dt>
<dd><p class="first">Loads templates from Django apps on the filesystem. For each app in
<tt class="docutils literal"><span class="pre">INSTALLED_APPS</span></tt>, the loader looks for a <tt class="docutils literal"><span class="pre">templates</span></tt> subdirectory. If
the directory exists, Django looks for templates in there.</p>
<p>This means you can store templates with your individual apps. This also
makes it easy to distribute Django apps with default templates.</p>
<p>For example, for this setting:</p>
<pre class="literal-block">
INSTALLED_APPS = ('myproject.polls', 'myproject.music')
</pre>
<p>...then <tt class="docutils literal"><span class="pre">get_template(&quot;foo&quot;)</span></tt> will look for templates in these
directories, in this order:</p>
<blockquote>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">/path/to/myproject/polls/templates/foo.html</span></tt></li>
<li><tt class="docutils literal"><span class="pre">/path/to/myproject/music/templates/music.html</span></tt></li>
</ul>
</blockquote>
<p class="last">Note that the loader performs an optimization when it is first imported:
It caches a list of which <tt class="docutils literal"><span class="pre">INSTALLED_APPS</span></tt> packages have a <tt class="docutils literal"><span class="pre">templates</span></tt>
subdirectory.</p>
</dd>
<dt><tt class="docutils literal"><span class="pre">django.core.template.loaders.eggs.load_template_source</span></tt></dt>
<dd>Just like <tt class="docutils literal"><span class="pre">app_directories</span></tt> above, but it loads templates from Python
eggs rather than from the filesystem.</dd>
</dl>
<p>Django uses the template loaders in order according to the <tt class="docutils literal"><span class="pre">TEMPLATE_LOADERS</span></tt>
setting. It uses each loader until a loader finds a match.</p>
</div>
</div>
</div>
<div class="section" id="extending-the-template-system">
<h2>Extending the template system</h2>
<p>Although the Django template language comes with several default tags and
filters, you might want to write your own. It's easy to do.</p>
<p>First, create a <tt class="docutils literal"><span class="pre">templatetags</span></tt> package in the appropriate Django app's
package. It should be on the same level as <tt class="docutils literal"><span class="pre">models</span></tt>, <tt class="docutils literal"><span class="pre">views</span></tt>, etc. For
example:</p>
<pre class="literal-block">
polls/
    models/
    templatetags/
    views/
</pre>
<p>Add two files to the <tt class="docutils literal"><span class="pre">templatetags</span></tt> package: an <tt class="docutils literal"><span class="pre">__init__.py</span></tt> file and a
file that will contain your custom tag/filter definitions. The name of the
latter file is the name you'll use to load the tags later. For example, if your
custom tags/filters are in a file called <tt class="docutils literal"><span class="pre">poll_extras.py</span></tt>, you'd do the
following in a template:</p>
<pre class="literal-block">
{% load poll_extras %}
</pre>
<p>The <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">%}</span></tt> tag looks at your <tt class="docutils literal"><span class="pre">INSTALLED_APPS</span></tt> setting and only allows
the loading of template libraries within installed Django apps. This is a
security feature: It allows you to host Python code for many template libraries
on a single computer without enabling access to all of them for every Django
installation.</p>
<p>If you write a template library that isn't tied to any particular models/views,
it's perfectly OK to have a Django app package that only contains a
<tt class="docutils literal"><span class="pre">templatetags</span></tt> package.</p>
<p>There's no limit on how many modules you put in the <tt class="docutils literal"><span class="pre">templatetags</span></tt> package.
Just keep in mind that a <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">load</span> <span class="pre">%}</span></tt> statement will load tags/filters for
the given Python module name, not the name of the app.</p>
<p>Once you've created that Python module, you'll just have to write a bit of
Python code, depending on whether you're writing filters or tags.</p>
<div class="admonition-behind-the-scenes admonition">
<p class="first admonition-title">Behind the scenes</p>
<p class="last">For a ton of examples, read the source code for Django's default filters
and tags. They're in <tt class="docutils literal"><span class="pre">django/core/template/defaultfilters.py</span></tt> and
<tt class="docutils literal"><span class="pre">django/core/template/defaulttags.py</span></tt>, respectively.</p>
</div>
<div class="section" id="writing-custom-template-filters">
<h3>Writing custom template filters</h3>
<p>Custom filters are just Python functions that take two arguments:</p>
<blockquote>
<ul class="simple">
<li>The value of the variable (input) -- not necessarily a string</li>
<li>The value of the argument -- always a string</li>
</ul>
</blockquote>
<p>Filter functions should always return something. They shouldn't raise
exceptions. They should fail silently. In case of error, they should return
either the original input or an empty string -- whichever makes more sense.</p>
<p>Here's an example filter definition:</p>
<pre class="literal-block">
def cut(value, arg):
    &quot;Removes all values of arg from the given string&quot;
    return value.replace(arg, '')
</pre>
<p>Most filters don't take arguments. For filters that don't take arguments, the
convention is to use a single underscore as the second argument to the filter
definition. Example:</p>
<pre class="literal-block">
def lower(value, _):
    &quot;Converts a string into all lowercase&quot;
    return value.lower()
</pre>
<p>When you've written your filter definition, you need to register it, to make it
available to Django's template language:</p>
<pre class="literal-block">
from django.core import template
template.register_filter('cut', cut, True)
template.register_filter('lower', lower, False)
</pre>
<p><tt class="docutils literal"><span class="pre">register_filter</span></tt> takes three arguments:</p>
<blockquote>
<ol class="arabic simple">
<li>The name of the filter -- a string.</li>
<li>The compilation function -- a Python function (not the name of the
function as a string).</li>
<li>A boolean, designating whether the filter requires an argument. This
tells Django's template parser whether to throw <tt class="docutils literal"><span class="pre">TemplateSyntaxError</span></tt>
when filter arguments are given (or missing).</li>
</ol>
</blockquote>
<p>The convention is to put all <tt class="docutils literal"><span class="pre">register_filter</span></tt> calls at the bottom of your
template-library module.</p>
</div>
<div class="section" id="writing-custom-template-tags">
<h3>Writing custom template tags</h3>
<p>Tags are more complex than filters, because tags can do anything.</p>
<div class="section" id="a-quick-overview">
<h4>A quick overview</h4>
<p>Above, this document explained that the template system works in a two-step
process: compiling and rendering. To define a custom template tag, you specify
how the compilation works and how the rendering works.</p>
<p>When Django compiles a template, it splits the raw template text into
''nodes''. Each node is an instance of <tt class="docutils literal"><span class="pre">django.core.template.Node</span></tt> and has
a <tt class="docutils literal"><span class="pre">render()</span></tt> method. A compiled template is, simply, a list of <tt class="docutils literal"><span class="pre">Node</span></tt>
objects. When you call <tt class="docutils literal"><span class="pre">render()</span></tt> on a compiled template object, the template
calls <tt class="docutils literal"><span class="pre">render()</span></tt> on each <tt class="docutils literal"><span class="pre">Node</span></tt> in its node list, with the given context.
The results are all concatenated together to form the output of the template.</p>
<p>Thus, to define a custom template tag, you specify how the raw template tag is
converted into a <tt class="docutils literal"><span class="pre">Node</span></tt> (the compilation function), and what the node's
<tt class="docutils literal"><span class="pre">render()</span></tt> method does.</p>
</div>
<div class="section" id="writing-the-compilation-function">
<h4>Writing the compilation function</h4>
<p>For each template tag the template parser encounters, it calls a Python
function with the tag contents and the parser object itself. This function is
responsible for returning a <tt class="docutils literal"><span class="pre">Node</span></tt> instance based on the contents of the tag.</p>
<p>By convention, the name of each compilation function should start with <tt class="docutils literal"><span class="pre">do_</span></tt>.</p>
<p>For example, let's write a template tag, <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">current_time</span> <span class="pre">%}</span></tt>, that displays
the current date/time, formatted according to a parameter given in the tag, in
<a class="reference" href="http://www.python.org/doc/current/lib/module-time.html#l2h-1941">strftime syntax</a>. It's a good idea to decide the tag syntax before anything
else. In our case, let's say the tag should be used like this:</p>
<pre class="literal-block">
&lt;p&gt;The time is {% current_time &quot;%Y-%M-%d %I:%M %p&quot; %}.&lt;/p&gt;
</pre>
<p>The parser for this function should grab the parameter and create a <tt class="docutils literal"><span class="pre">Node</span></tt>
object:</p>
<pre class="literal-block">
from django.core import template
def do_current_time(parser, token):
    try:
        # Splitting by None == splitting by spaces.
        tag_name, format_string = token.contents.split(None, 1)
    except ValueError:
        raise template.TemplateSyntaxError, &quot;%r tag requires an argument&quot; % token.contents[0]
    if not (format_string[0] == format_string[-1] and format_string[0] in ('&quot;', &quot;'&quot;)):
        raise template.TemplateSyntaxError, &quot;%r tag's argument should be in quotes&quot; % tag_name
    return CurrentTimeNode(format_string[1:-1])
</pre>
<p>Notes:</p>
<blockquote>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">parser</span></tt> is the template parser object. We don't need it in this
example.</li>
<li><tt class="docutils literal"><span class="pre">token.contents</span></tt> is a string of the raw contents of the tag. In our
example, it's <tt class="docutils literal"><span class="pre">'current_time</span> <span class="pre">&quot;%Y-%M-%d</span> <span class="pre">%I:%M</span> <span class="pre">%p&quot;'</span></tt>.</li>
<li>This function is responsible for raising
<tt class="docutils literal"><span class="pre">django.core.template.TemplateSyntaxError</span></tt>, with helpful messages, for
any syntax error.</li>
<li>The <tt class="docutils literal"><span class="pre">TemplateSyntaxError</span></tt> exceptions use the <tt class="docutils literal"><span class="pre">tag_name</span></tt> variable.
Don't hard-code the tag's name in your error messages, because that
couples the tag's name to your function. <tt class="docutils literal"><span class="pre">token.contents.split()[0]</span></tt>
will ''always'' be the name of your tag -- even when the tag has no
arguments.</li>
<li>The function returns a <tt class="docutils literal"><span class="pre">CurrentTimeNode</span></tt> with everything the node needs
to know about this tag. In this case, it just passes the argument --
<tt class="docutils literal"><span class="pre">&quot;%Y-%M-%d</span> <span class="pre">%I:%M</span> <span class="pre">%p&quot;</span></tt>. The leading and trailing quotes from the
template tag are removed in <tt class="docutils literal"><span class="pre">format_string[1:-1]</span></tt>.</li>
<li>The parsing is very low-level. The Django developers have experimented
with writing small frameworks on top of this parsing system, using
techniques such as EBNF grammars, but those experiments made the template
engine too slow. It's low-level because that's fastest.</li>
</ul>
</blockquote>
</div>
<div class="section" id="writing-the-renderer">
<h4>Writing the renderer</h4>
<p>The second step in writing custom tags is to define a <tt class="docutils literal"><span class="pre">Node</span></tt> subclass that
has a <tt class="docutils literal"><span class="pre">render()</span></tt> method.</p>
<p>Continuing the above example, we need to define <tt class="docutils literal"><span class="pre">CurrentTimeNode</span></tt>:</p>
<pre class="literal-block">
from django.core import template
import datetime
class CurrentTimeNode(template.Node):
    def __init__(self, format_string):
        self.format_string = format_string
    def render(self, context):
        return datetime.datetime.now().strftime(self.format_string)
</pre>
<p>Notes:</p>
<blockquote>
<ul class="simple">
<li><tt class="docutils literal"><span class="pre">__init__()</span></tt> gets the <tt class="docutils literal"><span class="pre">format_string</span></tt> from <tt class="docutils literal"><span class="pre">do_current_time()</span></tt>.
Always pass any options/parameters/arguments to a <tt class="docutils literal"><span class="pre">Node</span></tt> via its
<tt class="docutils literal"><span class="pre">__init__()</span></tt>.</li>
<li>The <tt class="docutils literal"><span class="pre">render()</span></tt> method is where the work actually happens.</li>
<li><tt class="docutils literal"><span class="pre">render()</span></tt> should never raise <tt class="docutils literal"><span class="pre">TemplateSyntaxError</span></tt> or any other
exception. It should fail silently, just as template filters should.</li>
</ul>
</blockquote>
<p>Ultimately, this decoupling of compilation and rendering results in an
efficient template system, because a template can render multiple context
without having to be parsed multiple times.</p>
</div>
<div class="section" id="registering-the-tag">
<h4>Registering the tag</h4>
<p>Finally, use a <tt class="docutils literal"><span class="pre">register_tag</span></tt> call, as in <tt class="docutils literal"><span class="pre">register_filter</span></tt> above. Example:</p>
<pre class="literal-block">
from django.core import template
template.register_tag('current_time', do_current_time)
</pre>
<p><tt class="docutils literal"><span class="pre">register_tag</span></tt> takes two arguments:</p>
<blockquote>
<ol class="arabic simple">
<li>The name of the template tag -- a string.</li>
<li>The compilation function -- a Python function (not the name of the
function as a string).</li>
</ol>
</blockquote>
</div>
<div class="section" id="setting-a-variable-in-the-context">
<h4>Setting a variable in the context</h4>
<p>The above example simply output a value. Generally, it's more flexible if your
template tags set template variables instead of outputting values. That way,
template authors can reuse the values that your template tags create.</p>
<p>To set a variable in the context, just use dictionary assignment on the context
object in the <tt class="docutils literal"><span class="pre">render()</span></tt> method. Here's an updated version of
<tt class="docutils literal"><span class="pre">CurrentTimeNode</span></tt> that sets a template variable <tt class="docutils literal"><span class="pre">current_time</span></tt> instead of
outputting it:</p>
<pre class="literal-block">
class CurrentTimeNode2(template.Node):
    def __init__(self, format_string):
        self.format_string = format_string
    def render(self, context):
        context['current_time'] = datetime.datetime.now().strftime(self.format_string)
        return ''
</pre>
<p>Note that <tt class="docutils literal"><span class="pre">render()</span></tt> returns the empty string. <tt class="docutils literal"><span class="pre">render()</span></tt> should always
return string output. If all the template tag does is set a variable,
<tt class="docutils literal"><span class="pre">render()</span></tt> should return the empty string.</p>
<p>Here's how you'd use this new version of the tag:</p>
<pre class="literal-block">
{% current_time &quot;%Y-%M-%d %I:%M %p&quot; %}&lt;p&gt;The time is {{ current_time }}.&lt;/p&gt;
</pre>
<p>But, there's a problem with <tt class="docutils literal"><span class="pre">CurrentTimeNode2</span></tt>: The variable name
<tt class="docutils literal"><span class="pre">current_time</span></tt> is hard-coded. This means you'll need to make sure your
template doesn't use <tt class="docutils literal"><span class="pre">{{</span> <span class="pre">current_time</span> <span class="pre">}}</span></tt> anywhere else, because the
<tt class="docutils literal"><span class="pre">{%</span> <span class="pre">current_time</span> <span class="pre">%}</span></tt> will blindly overwrite that variable's value. A cleaner
solution is to make the template tag specify the name of the output variable,
like so:</p>
<pre class="literal-block">
{% get_current_time &quot;%Y-%M-%d %I:%M %p&quot; as my_current_time %}
&lt;p&gt;The current time is {{ my_current_time }}.&lt;/p&gt;
</pre>
<p>To do that, you'll need to refactor both the compilation function and <tt class="docutils literal"><span class="pre">Node</span></tt>
class, like so:</p>
<pre class="literal-block">
class CurrentTimeNode3(template.Node):
    def __init__(self, format_string, var_name):
        self.format_string = format_string
        self.var_name = var_name
    def render(self, context):
        context[self.var_name] = datetime.datetime.now().strftime(self.format_string)
        return ''

import re
def do_current_time(parser, token):
    # This version uses a regular expression to parse tag contents.
    try:
        # Splitting by None == splitting by spaces.
        tag_name, arg = token.contents.split(None, 1)
    except ValueError:
        raise template.TemplateSyntaxError, &quot;%r tag requires arguments&quot; % token.contents[0]
    m = re.search(r'(.*?) as (\w+)', arg)
    if not m:
        raise template.TemplateSyntaxError, &quot;%r tag had invalid arguments&quot; % tag_name
    format_string, var_name = m.groups()
    if not (format_string[0] == format_string[-1] and format_string[0] in ('&quot;', &quot;'&quot;)):
        raise template.TemplateSyntaxError, &quot;%r tag's argument should be in quotes&quot; % tag_name
    return CurrentTimeNode3(format_string[1:-1], var_name)
</pre>
<p>The difference here is that <tt class="docutils literal"><span class="pre">do_current_time()</span></tt> grabs the format string and
the variable name, passing both to <tt class="docutils literal"><span class="pre">CurrentTimeNode3</span></tt>.</p>
</div>
<div class="section" id="parsing-until-another-block-tag">
<h4>Parsing until another block tag</h4>
<p>Template tags can work in tandem. For instance, the standard <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">comment</span> <span class="pre">%}</span></tt>
tag hides everything until <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">endcomment</span> <span class="pre">%}</span></tt>. To create a template tag such
as this, use <tt class="docutils literal"><span class="pre">parser.parse()</span></tt> in your compilation function.</p>
<p>Here's how the standard <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">comment</span> <span class="pre">%}</span></tt> tag is implemented:</p>
<pre class="literal-block">
def do_comment(parser, token):
    nodelist = parser.parse(('endcomment',))
    parser.delete_first_token()
    return CommentNode()

class CommentNode(template.Node):
    def render(self, context):
        return ''
</pre>
<p><tt class="docutils literal"><span class="pre">parser.parse()</span></tt> takes a tuple of names of block tags ''to parse until''. It
returns an instance of <tt class="docutils literal"><span class="pre">django.core.template.NodeList</span></tt>, which is a list of
all <tt class="docutils literal"><span class="pre">Node</span></tt> objects that the parser encountered ''before'' it encountered
any of the tags named in the tuple.</p>
<p>In <tt class="docutils literal"><span class="pre">&quot;nodelist</span> <span class="pre">=</span> <span class="pre">parser.parse(('endcomment',))&quot;</span></tt> in the above example,
<tt class="docutils literal"><span class="pre">nodelist</span></tt> is a list of all nodes between the <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">comment</span> <span class="pre">%}</span></tt> and
<tt class="docutils literal"><span class="pre">{%</span> <span class="pre">endcomment</span> <span class="pre">%}</span></tt>, not counting <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">comment</span> <span class="pre">%}</span></tt> and <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">endcomment</span> <span class="pre">%}</span></tt>
themselves.</p>
<p>After <tt class="docutils literal"><span class="pre">parser.parse()</span></tt> is called, the parser hasn't yet &quot;consumed&quot; the
<tt class="docutils literal"><span class="pre">{%</span> <span class="pre">endcomment</span> <span class="pre">%}</span></tt> tag, so the code needs to explicitly call
<tt class="docutils literal"><span class="pre">parser.delete_first_token()</span></tt>.</p>
<p><tt class="docutils literal"><span class="pre">CommentNode.render()</span></tt> simply returns an empty string. Anything between
<tt class="docutils literal"><span class="pre">{%</span> <span class="pre">comment</span> <span class="pre">%}</span></tt> and <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">endcomment</span> <span class="pre">%}</span></tt> is ignored.</p>
</div>
<div class="section" id="parsing-until-another-block-tag-and-saving-contents">
<h4>Parsing until another block tag, and saving contents</h4>
<p>In the previous example, <tt class="docutils literal"><span class="pre">do_comment()</span></tt> discarded everything between
<tt class="docutils literal"><span class="pre">{%</span> <span class="pre">comment</span> <span class="pre">%}</span></tt> and <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">endcomment</span> <span class="pre">%}</span></tt>. Instead of doing that, it's
possible to do something with the code between block tags.</p>
<p>For example, here's a custom template tag, <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">upper</span> <span class="pre">%}</span></tt>, that capitalizes
everything between itself and <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">endupper</span> <span class="pre">%}</span></tt>.</p>
<p>Usage:</p>
<pre class="literal-block">
{% upper %}This will appear in uppercase, {{ your_name }}.{% endupper %}
</pre>
<p>As in the previous example, we'll use <tt class="docutils literal"><span class="pre">parser.parse()</span></tt>. But this time, we
pass the resulting <tt class="docutils literal"><span class="pre">nodelist</span></tt> to the <tt class="docutils literal"><span class="pre">Node</span></tt>:</p>
<pre class="literal-block">
def do_upper(parser, token):
    nodelist = parser.parse(('endupper',))
    parser.delete_first_token()
    return UpperNode(nodelist)

class UpperNode(template.Node):
    def __init__(self, nodelist):
        self.nodelist = nodelist
    def render(self, context):
        output = self.nodelist.render(context)
        return output.upper()
</pre>
<p>The only new concept here is the <tt class="docutils literal"><span class="pre">self.nodelist.render(context)</span></tt> in
<tt class="docutils literal"><span class="pre">UpperNode.render()</span></tt>.</p>
<p>For more examples of complex rendering, see the source code for <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">if</span> <span class="pre">%}</span></tt>,
<tt class="docutils literal"><span class="pre">{%</span> <span class="pre">for</span> <span class="pre">%}</span></tt>, <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">ifequal</span> <span class="pre">%}</span></tt> and <tt class="docutils literal"><span class="pre">{%</span> <span class="pre">ifchanged</span> <span class="pre">%}</span></tt>. They live in
<tt class="docutils literal"><span class="pre">django/core/template/defaulttags.py</span></tt>.</p>
</div>
</div>
</div>
</div>





<div id="content-secondary">
<h2 id="comments">Comments</h2>



<h2>Post a comment</h2>

<p class="small quiet"><strong>Note:</strong> Please only use the comments for
questions/critcisms/suggestions on the docs; if you experience errors please <a
href="http://code.djangoproject.com/newticket">file a ticket</a>, ask in the IRC
channel, or post to the <a href="http://groups-beta.google.com/group/django-users">
django-users list</a>. Comments will be periodically reviewed, integrated into
the documentation proper, and removed.</p>



<form action="http://www.djangoproject.com/comments/postfree/" method="post">
<p>Your name: <input type="text" id="id_person_name" name="person_name" /></p>
<p>Comment:<br /><textarea name="comment" id="id_comment" rows="10" cols="60"></textarea></p>
<input type="hidden" name="options" value="ip" />
<input type="hidden" name="target" value="13:38" />
<input type="hidden" name="gonzo" value="394123ae8696689a74c82a4deed668cb" />
<p><input type="submit" name="preview" value="Preview comment" /></p>
</form>


</div>

		</div>
		<!-- END #content-main -->
		<div id="content-related" class="sidebar">
		<h2>Contents</h2><ul class='toc'><li><a class="reference" href="#basics" id="id1" name="id1">Basics</a></li>
<li><p class="first"><a class="reference" href="#using-the-template-system" id="id2" name="id2">Using the template system</a></p>
<ul class="simple">
<li><a class="reference" href="#compiling-a-string" id="id3" name="id3">Compiling a string</a></li>
<li><a class="reference" href="#rendering-a-context" id="id4" name="id4">Rendering a context</a></li>
<li><a class="reference" href="#playing-with-context-objects" id="id5" name="id5">Playing with Context objects</a></li>
<li><a class="reference" href="#subclassing-context-djangocontext" id="id6" name="id6">Subclassing Context: DjangoContext</a></li>
<li><a class="reference" href="#loading-templates" id="id7" name="id7">Loading templates</a><ul>
<li><a class="reference" href="#the-template-dirs-setting" id="id8" name="id8">The TEMPLATE_DIRS setting</a></li>
<li><a class="reference" href="#the-python-api" id="id9" name="id9">The Python API</a></li>
<li><a class="reference" href="#using-subdirectories" id="id10" name="id10">Using subdirectories</a></li>
<li><a class="reference" href="#loader-types" id="id11" name="id11">Loader types</a></li>
</ul>
</li>
</ul>
</li>
<li><p class="first"><a class="reference" href="#extending-the-template-system" id="id12" name="id12">Extending the template system</a></p>
<ul class="simple">
<li><a class="reference" href="#writing-custom-template-filters" id="id13" name="id13">Writing custom template filters</a></li>
<li><a class="reference" href="#writing-custom-template-tags" id="id14" name="id14">Writing custom template tags</a><ul>
<li><a class="reference" href="#a-quick-overview" id="id15" name="id15">A quick overview</a></li>
<li><a class="reference" href="#writing-the-compilation-function" id="id16" name="id16">Writing the compilation function</a></li>
<li><a class="reference" href="#writing-the-renderer" id="id17" name="id17">Writing the renderer</a></li>
<li><a class="reference" href="#registering-the-tag" id="id18" name="id18">Registering the tag</a></li>
<li><a class="reference" href="#setting-a-variable-in-the-context" id="id19" name="id19">Setting a variable in the context</a></li>
<li><a class="reference" href="#parsing-until-another-block-tag" id="id20" name="id20">Parsing until another block tag</a></li>
<li><a class="reference" href="#parsing-until-another-block-tag-and-saving-contents" id="id21" name="id21">Parsing until another block tag, and saving contents</a></li>
</ul>
</li>
</ul>
</li>
</ul>
		</div>
		<!-- END #content-related -->

		</div>
		<!-- END #content -->
		<div id="footer">
			<p>&copy; 2005 <a href="http://www.ljworld.com/">Lawrence Journal-World</a> unless otherwise noted. Django is a registered trademark of Lawrence Journal-World.</p>
		</div>
	</div>
	<!-- END #container -->
	</body>

<!-- Mirrored from www.djangoproject.com/documentation/templates_python/ by HTTrack Website Copier/3.x [XR&CO'2005], Fri, 25 Nov 2005 13:28:51 GMT -->
<!-- Added by HTTrack --><meta http-equiv="content-type" content="text/html;charset=utf-8"><!-- /Added by HTTrack -->
</html>

