Source

django / docs / templates_python.txt

Full commit
  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
====================================================
The Django template language: For Python programmers
====================================================

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
`The Django template language: For template authors`_.

.. _`The Django template language: For template authors`: http://www.djangoproject.com/documentation/templates/

Basics
======

A **template** is a text document, or a normal Python string, that is marked-up
using the Django template language. A template can contain **block tags** or
**variables**.

A **block tag** is a symbol within a template that does something.

This definition is deliberately vague. For example, a block tag can output
content, serve as a control structure (an "if" statement or "for" loop), grab
content from a database or enable access to other template tags.

Block tags are surrounded by ``"{%"`` and ``"%}"``.

Example template with block tags::

    {% if is_logged_in %}Thanks for logging in!{% else %}Please log in.{% endif %}

A **variable** is a symbol within a template that outputs a value.

Variable tags are surrounded by ``"{{"`` and ``"}}"``.

Example template with variables::

    My first name is {{ first_name }}. My last name is {{ last_name }}.

A **context** is a "variable name" -> "variable value" mapping that is passed
to a template.

A template **renders** a context by replacing the variable "holes" with values
from the context and executing all block tags.

Using the template system
=========================

Using the template system in Python is a two-step process:

    * First, you compile the raw template code into a ``Template`` object.
    * Then, you call the ``render()`` method of the ``Template`` object with a
      given context.

Compiling a string
------------------

The easiest way to create a ``Template`` object is by instantiating it
directly. The class lives at ``django.core.template.Template``. The constructor
takes one argument -- the raw template code::

    >>> from django.core.template import Template
    >>> t = Template("My name is {{ my_name }}.")
    >>> print t
    <django.core.template.Template instance>

.. admonition:: Behind the scenes

    The system only parses your raw template code once -- when you create the
    ``Template`` object. From then on, it's stored internally as a "node"
    structure for performance.

    Even the parsing itself is quite fast. Most of the parsing happens via a
    single call to a single, short, regular expression.

Rendering a context
-------------------

Once you have a compiled ``Template`` object, you can render a context -- or
multiple contexts -- with it. The ``Context`` class lives at
``django.core.template.Context``, and the constructor takes one (optional)
argument: a dictionary mapping variable names to variable values. Call the
``Template`` object's ``render()`` method with the context to "fill" the
template::

    >>> from django.core.template import Context, Template
    >>> t = Template("My name is {{ my_name }}.")

    >>> c = Context({"my_name": "Adrian"})
    >>> t.render(c)
    "My name is Adrian."

    >>> c = Context({"my_name": "Dolores"})
    >>> t.render(c)
    "My name is Dolores."

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

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

    * Dictionary lookup. Example: ``foo["bar"]``
    * Attribute lookup. Example: ``foo.bar``
    * Method call. Example: ``foo.bar()``
    * List-index lookup. Example: ``foo[bar]``

The template system uses the first lookup type that works. It's short-circuit
logic.

Here are a few examples::

    >>> from django.core.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."

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

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

Method lookups are slightly more complex than the other lookup types. Here are
some things to keep in mind:

    * If, during the method lookup, a method raises an exception, the exception
      will be propagated, unless the exception subclasses
      ``django.core.template.SilentVariableFailure``. If the exception
      subclasses ``SilentVariableFailure``, the variable will render as an
      empty string. Example::

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

        >>> from django.core.template import SilentVariableFailure
        >>> class SilentAssertionError(SilentVariableFailure): pass
        >>> class PersonClass4:
        ...     def first_name(self):
        ...         raise SilentAssertionError, "foo"
        >>> p = PersonClass4()
        >>> t.render(Context({"person": p}))
        "My name is ."

    * 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).

    * Obviously, some methods have side effects, and it'd be either foolish or
      a security hole to allow the template system to access them.

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

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

      To prevent this, set a function attribute ``alters_data`` on the method.
      The template system won't execute a method if the method has
      ``alters_data=True`` set. The dynamically-generated ``delete()`` and
      ``save()`` methods on Django model objects get ``alters_data=True``
      automatically. Example::

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

How invalid variables are handled
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In Django 0.91, if a variable doesn't exist, the template system fails
silently. The variable is replaced with an empty string::

    >>> t = Template("My name is {{ my_name }}.")
    >>> c = Context({"foo": "bar"})
    >>> t.render(c)
    "My name is ."

This applies to any level of lookup::

    >>> t = Template("My name is {{ person.fname }} {{ person.lname }}.")
    >>> c = Context({"person": {"fname": "Stan"}})
    >>> t.render(c)
    "My name is Stan ."

In the Django development version, if a variable doesn't exist, the template
system inserts the value of the ``TEMPLATE_STRING_IF_INVALID`` setting, which
is set to ``''`` (the empty string) by default.

Playing with Context objects
----------------------------

Most of the time, you'll instantiate ``Context`` objects by passing in a
fully-populated dictionary to ``Context()``. But you can add and delete items
from a ``Context`` object once it's been instantiated, too, using standard
dictionary syntax::

    >>> c = Context({"foo": "bar"})
    >>> c['foo']
    'bar'
    >>> del c['foo']
    >>> c['foo']
    ''
    >>> c['newvariable'] = 'hello'
    >>> c['newvariable']
    'hello'

A ``Context`` object is a stack. That is, you can ``push()`` and ``pop()`` it.
If you ``pop()`` too much, it'll raise
``django.core.template.ContextPopException``::

    >>> c = Context()
    >>> c['foo'] = 'first level'
    >>> c.push()
    >>> c['foo'] = 'second level'
    >>> c['foo']
    'second level'
    >>> c.pop()
    >>> c['foo']
    'first level'
    >>> c['foo'] = 'overwritten'
    >>> c['foo']
    'overwritten'
    >>> c.pop()
    Traceback (most recent call last):
    ...
    django.core.template.ContextPopException

Using a ``Context`` as a stack comes in handy in some custom template tags, as
you'll see below.

Subclassing Context: DjangoContext
----------------------------------

Django comes with a special ``Context`` class,
``django.core.extensions.DjangoContext``, that acts slightly differently than
the normal ``django.core.template.Context``. The first difference is that takes
an `HttpRequest object`_ as its first argument. For example::

    c = DjangoContext(request, {
        'foo': 'bar',
    }

The second difference is that it automatically populates the context with a few
variables, according to your `TEMPLATE_CONTEXT_PROCESSORS setting`_.

The ``TEMPLATE_CONTEXT_PROCESSORS`` setting is a tuple of callables that take a
request object as their argument and return a dictionary of items to be merged
into the context. By default, ``TEMPLATE_CONTEXT_PROCESSORS`` is set to::

    ("django.core.context_processors.auth",
    "django.core.context_processors.debug",
    "django.core.context_processors.i18n")

Each processor is applied in order. That means, if one processor adds a
variable to the context and a second processor adds a variable with the same
name, the second will override the first. The default processors are explained
below.

Also, you can give ``DjangoContext`` a list of additional processors, using the
optional, third positional argument, ``processors``. In this example, the
``DjangoContext`` instance gets a ``ip_address`` variable::

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

    def some_view(request):
        # ...
        return DjangoContext(request, {
            'foo': 'bar',
        }, [ip_address_processor])

Here's what each of the default processors does:

.. _HttpRequest object: http://www.djangoproject.com/documentation/request_response/#httprequest-objects
.. _TEMPLATE_CONTEXT_PROCESSORS setting: http://www.djangoproject.com/documentation/settings/#template-context-processors

django.core.context_processors.auth
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every
``DjangoContext`` will contain these three variables:

    * ``user`` -- An ``auth.User`` instance representing the currently
      logged-in user (or an ``AnonymousUser`` instance, if the client isn't
      logged in). See the `user authentication docs`.
    * ``messages`` -- A list of ``auth.Message`` objects for the currently
      logged-in user.
    * ``perms`` -- An instance of ``django.core.context_processors.PermWrapper``,
      representing the permissions that the currently logged-in user has. See
      the `permissions docs`_.

.. _user authentication docs: http://www.djangoproject.com/documentation/authentication/#users
.. _permissions docs: http://www.djangoproject.com/documentation/authentication/#permissions

django.core.context_processors.debug
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every
``DjangoContext`` will contain these two variables -- but only if your
``DEBUG`` setting is set to ``True`` and the request's IP address
(``request.META['REMOTE_ADDR']``) is in the ``INTERNAL_IPS`` setting:

    * ``debug`` -- ``True``. You can use this in templates to test whether
      you're in ``DEBUG`` mode.
    * ``sql_queries`` -- A list of ``{'sql': ..., 'time': ...}`` 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.

django.core.context_processors.i18n
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every
``DjangoContext`` will contain these two variables:

    * ``LANGUAGES`` -- The value of the `LANGUAGES setting`_.
    * ``LANGUAGE_CODE`` -- ``request.LANGUAGE_CODE``, if it exists. Otherwise,
      the value of the `LANGUAGE_CODE setting`_.

See the `internationalization docs`_ for more.

.. _LANGUAGES setting: http://www.djangoproject.com/documentation/settings/#languages
.. _LANGUAGE_CODE setting: http://www.djangoproject.com/documentation/settings/#language-code
.. _internationalization docs: http://www.djangoproject.com/documentation/i18n/

django.core.context_processors.request
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

**New in Django development version**

If ``TEMPLATE_CONTEXT_PROCESSORS`` contains this processor, every
``DjangoContext`` will contain a variable ``request``, which is the current
`HttpRequest object`_. Note that this processor is not enabled by default;
you'll have to activate it.

Loading templates
-----------------

Generally, you'll store templates in files on your filesystem rather than using
the low-level ``Template`` API yourself. Save templates in a file with an
".html" extension in a directory specified as a **template directory**.

If you don't like the requirement that templates have an ".html" extension,
change your ``TEMPLATE_FILE_EXTENSION`` setting. It's set to ``".html"`` by
default.

Also, the .html extension doesn't mean templates can contain only HTML. They
can contain whatever textual content you want.

The TEMPLATE_DIRS setting
~~~~~~~~~~~~~~~~~~~~~~~~~

Tell Django what your template directories are by using the ``TEMPLATE_DIRS``
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::

    TEMPLATE_DIRS = (
        "/home/html/templates/lawrence.com",
        "/home/html/templates/default",
    )

Your templates can go anywhere you want, as long as the directories and
templates are readable by the Web server.

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

The Python API
~~~~~~~~~~~~~~

Django has two ways to load templates from files:

``django.core.template.loader.get_template(template_name)``
    ``get_template`` returns the compiled template (a ``Template`` object) for
    the template with the given name. If the template doesn't exist, it raises
    ``django.core.template.TemplateDoesNotExist``.

``django.core.template.loader.select_template(template_name_list)``
    ``select_template`` is just like ``get_template``, except it takes a list
    of template names. Of the list, it returns the first template that exists.

For example, if you call ``get_template("story_detail")`` and have the above
``TEMPLATE_DIRS`` setting, here are the files Django will look for, in order:

    * ``/home/html/templates/lawrence.com/story_detail.html``
    * ``/home/html/templates/default/story_detail.html``

If you call ``select_template(["story_253_detail", "story_detail"])``, here's
what Django will look for:

    * ``/home/html/templates/lawrence.com/story_253_detail.html``
    * ``/home/html/templates/default/story_253_detail.html``
    * ``/home/html/templates/lawrence.com/story_detail.html``
    * ``/home/html/templates/default/story_detail.html``

When Django finds a template that exists, it stops looking.

.. admonition:: Tip

    You can use ``select_template`` for super-flexible "templatability." For
    example, if you've written a news story and want some stories to have
    custom templates, use something like
    ``select_template(["story_%s_detail" % story.id, "story_detail"])``.
    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.

Using subdirectories
~~~~~~~~~~~~~~~~~~~~

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.

Do this for your own sanity. Storing all templates in the root level of a
single directory gets messy.

To load a template that's within a subdirectory, just use a slash, like so::

    get_template("news/story_detail")

Loader types
~~~~~~~~~~~~

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 ``TEMPLATE_LOADERS`` setting.
``TEMPLATE_LOADERS`` should be a tuple of strings, where each string represents
a template loader. Here are the built-in template loaders:

``django.core.template.loaders.filesystem.load_template_source``
    Loads templates from the filesystem, according to ``TEMPLATE_DIRS``.

``django.core.template.loaders.app_directories.load_template_source``
    Loads templates from Django apps on the filesystem. For each app in
    ``INSTALLED_APPS``, the loader looks for a ``templates`` subdirectory. If
    the directory exists, Django looks for templates in there.

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

    For example, for this setting::

        INSTALLED_APPS = ('myproject.polls', 'myproject.music')

    ...then ``get_template("foo")`` will look for templates in these
    directories, in this order:

        * ``/path/to/myproject/polls/templates/foo.html``
        * ``/path/to/myproject/music/templates/foo.html``

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

``django.core.template.loaders.eggs.load_template_source``
    Just like ``app_directories`` above, but it loads templates from Python
    eggs rather than from the filesystem.

Django uses the template loaders in order according to the ``TEMPLATE_LOADERS``
setting. It uses each loader until a loader finds a match.

Extending the template system
=============================

Although the Django template language comes with several default tags and
filters, you might want to write your own. It's easy to do.

First, create a ``templatetags`` package in the appropriate Django app's
package. It should be on the same level as ``models``, ``views.py``, etc. For
example::

    polls/
        models/
        templatetags/

Add two files to the ``templatetags`` package: an ``__init__.py`` 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 ``poll_extras.py``, you'd do the
following in a template::

    {% load poll_extras %}

The ``{% load %}`` tag looks at your ``INSTALLED_APPS`` 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.

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
``templatetags`` package.

There's no limit on how many modules you put in the ``templatetags`` package.
Just keep in mind that a ``{% load %}`` statement will load tags/filters for
the given Python module name, not the name of the app.

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.

To be a valid tag library, the module contain a module-level variable named
``register`` that is a ``template.Library`` instance, in which all the tags and
filters are registered. So, near the top of your module, put the following::

    from django.core import template

    register = template.Library()

.. admonition:: Behind the scenes

    For a ton of examples, read the source code for Django's default filters
    and tags. They're in ``django/core/template/defaultfilters.py`` and
    ``django/core/template/defaulttags.py``, respectively.

Writing custom template filters
-------------------------------

Custom filters are just Python functions that take one or two arguments:

    * The value of the variable (input) -- not necessarily a string.
    * The value of the argument -- this can have a default value, or be left
      out altogether.

For example, in the filter ``{{ var|foo:"bar" }}``, the filter ``foo`` would be
passed the variable ``var`` and the argument ``"bar"``.

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.

Here's an example filter definition::

    def cut(value, arg):
        "Removes all values of arg from the given string"
        return value.replace(arg, '')

And here's an example of how that filter would be used::

    {{ somevariable|cut:"0" }}

Most filters don't take arguments. In this case, just leave the argument out of
your function. Example::

    def lower(value): # Only one argument.
        "Converts a string into all lowercase"
        return value.lower()

When you've written your filter definition, you need to register it with
your ``Library`` instance, to make it available to Django's template language::

    register.filter('cut', cut)
    register.filter('lower', lower)

The ``Library.filter()`` method takes two arguments:

    1. The name of the filter -- a string.
    2. The compilation function -- a Python function (not the name of the
       function as a string).

If you're using Python 2.4 or above, you can use ``register.filter()`` as a
decorator instead::

    @register.filter(name='cut')
    def cut(value, arg):
        return value.replace(arg, '')

    @register.filter
    def lower(value):
        return value.lower()

If you leave off the ``name`` argument, as in the second example above, Django
will use the function's name as the filter name.

Writing custom template tags
----------------------------

Tags are more complex than filters, because tags can do anything.

A quick overview
~~~~~~~~~~~~~~~~

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.

When Django compiles a template, it splits the raw template text into
''nodes''. Each node is an instance of ``django.core.template.Node`` and has
a ``render()`` method. A compiled template is, simply, a list of ``Node``
objects. When you call ``render()`` on a compiled template object, the template
calls ``render()`` on each ``Node`` in its node list, with the given context.
The results are all concatenated together to form the output of the template.

Thus, to define a custom template tag, you specify how the raw template tag is
converted into a ``Node`` (the compilation function), and what the node's
``render()`` method does.

Writing the compilation function
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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 ``Node`` instance based on the contents of the tag.

For example, let's write a template tag, ``{% current_time %}``, that displays
the current date/time, formatted according to a parameter given in the tag, in
`strftime syntax`_. 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>The time is {% current_time "%Y-%M-%d %I:%M %p" %}.</p>

.. _`strftime syntax`: http://www.python.org/doc/current/lib/module-time.html#l2h-1941

The parser for this function should grab the parameter and create a ``Node``
object::

    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, "%r tag requires an argument" % token.contents[0]
        if not (format_string[0] == format_string[-1] and format_string[0] in ('"', "'")):
            raise template.TemplateSyntaxError, "%r tag's argument should be in quotes" % tag_name
        return CurrentTimeNode(format_string[1:-1])

Notes:

    * ``parser`` is the template parser object. We don't need it in this
      example.

    * ``token.contents`` is a string of the raw contents of the tag. In our
      example, it's ``'current_time "%Y-%M-%d %I:%M %p"'``.

    * This function is responsible for raising
      ``django.core.template.TemplateSyntaxError``, with helpful messages, for
      any syntax error.

    * The ``TemplateSyntaxError`` exceptions use the ``tag_name`` variable.
      Don't hard-code the tag's name in your error messages, because that
      couples the tag's name to your function. ``token.contents.split()[0]``
      will ''always'' be the name of your tag -- even when the tag has no
      arguments.

    * The function returns a ``CurrentTimeNode`` with everything the node needs
      to know about this tag. In this case, it just passes the argument --
      ``"%Y-%M-%d %I:%M %p"``. The leading and trailing quotes from the
      template tag are removed in ``format_string[1:-1]``.

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

Writing the renderer
~~~~~~~~~~~~~~~~~~~~

The second step in writing custom tags is to define a ``Node`` subclass that
has a ``render()`` method.

Continuing the above example, we need to define ``CurrentTimeNode``::

    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)

Notes:

    * ``__init__()`` gets the ``format_string`` from ``do_current_time()``.
      Always pass any options/parameters/arguments to a ``Node`` via its
      ``__init__()``.

    * The ``render()`` method is where the work actually happens.

    * ``render()`` should never raise ``TemplateSyntaxError`` or any other
      exception. It should fail silently, just as template filters should.

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.

Registering the tag
~~~~~~~~~~~~~~~~~~~

Finally, register the tag with your module's ``Library`` instance, as explained
in "Writing custom template filters" above. Example::

    register.tag('current_time', do_current_time)

The ``tag()`` method takes two arguments:

    1. The name of the template tag -- a string. If this is left out, the
       name of the compilation function will be used.
    2. The compilation function -- a Python function (not the name of the
       function as a string).

As with filter registration, it is also possible to use this as a decorator, in
Python 2.4 and above::

    @register.tag(name="current_time")
    def do_current_time(parser, token):
        # ...

    @register.tag
    def shout(parser, token):
        # ...

If you leave off the ``name`` argument, as in the second example above, Django
will use the function's name as the tag name.

Setting a variable in the context
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.

To set a variable in the context, just use dictionary assignment on the context
object in the ``render()`` method. Here's an updated version of
``CurrentTimeNode`` that sets a template variable ``current_time`` instead of
outputting it::

    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 ''

Note that ``render()`` returns the empty string. ``render()`` should always
return string output. If all the template tag does is set a variable,
``render()`` should return the empty string.

Here's how you'd use this new version of the tag::

    {% current_time "%Y-%M-%d %I:%M %p" %}<p>The time is {{ current_time }}.</p>

But, there's a problem with ``CurrentTimeNode2``: The variable name
``current_time`` is hard-coded. This means you'll need to make sure your
template doesn't use ``{{ current_time }}`` anywhere else, because the
``{% current_time %}`` 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::

    {% get_current_time "%Y-%M-%d %I:%M %p" as my_current_time %}
    <p>The current time is {{ my_current_time }}.</p>

To do that, you'll need to refactor both the compilation function and ``Node``
class, like so::

    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, "%r tag requires arguments" % token.contents[0]
        m = re.search(r'(.*?) as (\w+)', arg)
        if not m:
            raise template.TemplateSyntaxError, "%r tag had invalid arguments" % tag_name
        format_string, var_name = m.groups()
        if not (format_string[0] == format_string[-1] and format_string[0] in ('"', "'")):
            raise template.TemplateSyntaxError, "%r tag's argument should be in quotes" % tag_name
        return CurrentTimeNode3(format_string[1:-1], var_name)

The difference here is that ``do_current_time()`` grabs the format string and
the variable name, passing both to ``CurrentTimeNode3``.

Parsing until another block tag
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Template tags can work in tandem. For instance, the standard ``{% comment %}``
tag hides everything until ``{% endcomment %}``. To create a template tag such
as this, use ``parser.parse()`` in your compilation function.

Here's how the standard ``{% comment %}`` tag is implemented::

    def do_comment(parser, token):
        nodelist = parser.parse(('endcomment',))
        parser.delete_first_token()
        return CommentNode()

    class CommentNode(template.Node):
        def render(self, context):
            return ''

``parser.parse()`` takes a tuple of names of block tags ''to parse until''. It
returns an instance of ``django.core.template.NodeList``, which is a list of
all ``Node`` objects that the parser encountered ''before'' it encountered
any of the tags named in the tuple.

In ``"nodelist = parser.parse(('endcomment',))"`` in the above example,
``nodelist`` is a list of all nodes between the ``{% comment %}`` and
``{% endcomment %}``, not counting ``{% comment %}`` and ``{% endcomment %}``
themselves.

After ``parser.parse()`` is called, the parser hasn't yet "consumed" the
``{% endcomment %}`` tag, so the code needs to explicitly call
``parser.delete_first_token()``.

``CommentNode.render()`` simply returns an empty string. Anything between
``{% comment %}`` and ``{% endcomment %}`` is ignored.

Parsing until another block tag, and saving contents
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the previous example, ``do_comment()`` discarded everything between
``{% comment %}`` and ``{% endcomment %}``. Instead of doing that, it's
possible to do something with the code between block tags.

For example, here's a custom template tag, ``{% upper %}``, that capitalizes
everything between itself and ``{% endupper %}``.

Usage::

    {% upper %}This will appear in uppercase, {{ your_name }}.{% endupper %}

As in the previous example, we'll use ``parser.parse()``. But this time, we
pass the resulting ``nodelist`` to the ``Node``::

    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()

The only new concept here is the ``self.nodelist.render(context)`` in
``UpperNode.render()``.

For more examples of complex rendering, see the source code for ``{% if %}``,
``{% for %}``, ``{% ifequal %}`` and ``{% ifchanged %}``. They live in
``django/core/template/defaulttags.py``.