Jinja2 supports extensions that can add extra filters, tests, globals or even extend the parser. The main motivation of extensions is it to move often used code into a reusable class like adding support for internationalization.
Extensions are added to the Jinja2 environment at creation time. Once the environment is created additional extensions cannot be added. To add an extension pass a list of extension classes or import paths to the environment parameter of the :class:`Environment` constructor. The following example creates a Jinja2 environment with the i18n extension loaded:
jinja_env = Environment(extensions=['jinja2.ext.i18n'])
Jinja2 currently comes with one extension, the i18n extension. It can be used in combination with gettext or babel. If the i18n extension is enabled Jinja2 provides a trans statement that marks the wrapped string as translatable and calls gettext.
After enabling dummy _ function that forwards calls to gettext is added to the environment globals. An internationalized application then has to provide at least an gettext and optoinally a ngettext function into the namespace. Either globally or for each rendering.
After enabling of the extension the environment provides the following additional methods:
For a web application that is available in multiple languages but gives all the users the same language (for example a multilingual forum software installed for a French community) may load the translations once and add the translation methods to the environment at environment generation time:
translations = get_gettext_translations() env = Environment(extensions=['jinja.ext.i18n']) env.install_gettext_translations(translations)
The get_gettext_translations function would return the translator for the current configuration. (For example by using gettext.find)
The usage of the i18n extension for template designers is covered as part :ref:`of the template documentation <i18n-in-templates>`.
By writing extensions you can add custom tags to Jinja2. This is a non trival task and usually not needed as the default tags and expressions cover all common use cases. The i18n extension is a good example of why extensions are useful, another one would be fragment caching.
When writing extensions you have to keep in mind that you are working with the Jinja2 template compiler which does not validate the node tree you are possing to it. If the AST is malformed you will get all kinds of compiler or runtime errors that are horrible to debug. Always make sure you are using the nodes you create correctly. The API documentation below shows which nodes exist and how to use them.
The following example implements a cache tag for Jinja2 by using the Werkzeug caching contrib module:
And here is how you use it in an environment:
from jinja2 import Environment from werkzeug.contrib.cache import SimpleCache env = Environment(extensions=[FragmentCacheExtension]) env.fragment_cache = SimpleCache()
Extensions always have to extend the :class:`jinja2.ext.Extension` class:
The parser passed to :meth:`Extension.parse` provides ways to parse expressions of different types. The following methods may be used by extensions:
The AST (Abstract Syntax Tree) is used to represent a template after parsing. It's build of nodes that the compiler then converts into executable Python code objects. Extensions that provide custom statements can return nodes to execute custom Python code.
The list below describes all nodes that are currently available. The AST may change between Jinja2 versions but will stay backwards compatible.
For more information have a look at the repr of :meth:`jinja2.Environment.parse`.