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 Environment constructor. The following
example creates a Jinja2 environment with the i18n extension loaded:
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 optionally a ngettext function into the
namespace. Either globally or for each rendering.
Installs a translation globally for that environment. The tranlations
object provided must implement at least ugettext and ungettext.
The gettext.NullTranslations and gettext.GNUTranslations classes
as well as Babels Translations class are supported.
Install dummy gettext functions. This is useful if you want to prepare
the application for internationalization but don’t want to implement the
full internationalization system yet.
Installs the given gettext and ngettext callables into the
environment as globals. They are supposed to behave exactly like the
standard library’s gettext.ugettext() and
gettext.ungettext() functions.
If newstyle is activated, the callables are wrapped to work like
newstyle callables. See Newstyle Gettext for more information.
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:
Starting with version 2.5 you can use newstyle gettext calls. These are
inspired by trac’s internal gettext functions and are fully supported by
the babel extraction tool. They might not work as expected by other
extraction tools in case you are not using Babel’s.
What’s the big difference between standard and newstyle gettext calls? In
general they are less to type and less error prone. Also if they are used
in an autoescaping environment they better support automatic escaping.
Here some common differences between old and new calls:
The advantages of newstyle gettext is that you have less to type and that
named placeholders become mandatory. The latter sounds like a
disadvantage but solves a lot of troubles translators are often facing
when they are unable to switch the positions of two placeholder. With
newstyle gettext, all format strings look the same.
Furthermore with newstyle gettext, string formatting is also used if no
placeholders are used which makes all strings behave exactly the same.
Last but not least are newstyle gettext calls able to properly mark
strings for autoescaping which solves lots of escaping related issues many
templates are experiencing over time when using autoescaping.
The “do” aka expression-statement extension adds a simple do tag to the
template engine that works like a variable expression but ignores the
return value.
This extension adds support for the with keyword. Using this keyword it
is possible to enforce a nested scope in a template. Variables can be
declared directly in the opening block of the with statement or using a
standard set statement directly within.
The autoescape extension allows you to toggle the autoescape feature from
within the template. If the environment’s autoescape
setting is set to False it can be activated, if it’s True it can be
deactivated. The setting overriding is scoped.
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 passing
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:
fromjinja2importnodesfromjinja2.extimportExtensionclassFragmentCacheExtension(Extension):# a set of names that trigger the extension.tags=set(['cache'])def__init__(self,environment):super(FragmentCacheExtension,self).__init__(environment)# add the defaults to the environmentenvironment.extend(fragment_cache_prefix='',fragment_cache=None)defparse(self,parser):# the first token is the token that started the tag. In our case# we only listen to ``'cache'`` so this will be a name token with# `cache` as value. We get the line number so that we can give# that line number to the nodes we create by hand.lineno=parser.stream.next().lineno# now we parse a single expression that is used as cache key.args=[parser.parse_expression()]# if there is a comma, the user provided a timeout. If not use# None as second parameter.ifparser.stream.skip_if('comma'):args.append(parser.parse_expression())else:args.append(nodes.Const(None))# now we parse the body of the cache block up to `endcache` and# drop the needle (which would always be `endcache` in that case)body=parser.parse_statements(['name:endcache'],drop_needle=True)# now return a `CallBlock` node that calls our _cache_support# helper method on this extension.returnnodes.CallBlock(self.call_method('_cache_support',args),[],[],body).set_lineno(lineno)def_cache_support(self,name,timeout,caller):"""Helper callback."""key=self.environment.fragment_cache_prefix+name# try to load the block from the cache# if there is no fragment in the cache, render it and store# it in the cache.rv=self.environment.fragment_cache.get(key)ifrvisnotNone:returnrvrv=caller()self.environment.fragment_cache.add(key,rv,timeout)returnrv
Extensions can be used to add extra functionality to the Jinja template
system at the parser level. Custom extensions are bound to an environment
but may not store environment specific data on self. The reason for
this is that an extension can be bound to another environment (for
overlays) by creating a copy and reassigning the environment attribute.
As extensions are created by the environment they cannot accept any
arguments for configuration. One may want to work around that by using
a factory function, but that is not possible as extensions are identified
by their import name. The correct way to configure the extension is
storing the configuration values on the environment. Because this way the
environment ends up acting as central configuration storage the
attributes may clash which is why extensions have to ensure that the names
they choose for configuration are not too generic. prefix for example
is a terrible name, fragment_cache_prefix on the other hand is a good
name as includes the name of the extension (fragment cache).
This method is called before the actual lexing and can be used to
preprocess the source. The filename is optional. The return value
must be the preprocessed source.
It’s passed a TokenStream that can be used
to filter tokens returned. This method has to return an iterable of
Tokens, but it doesn’t have to return a
TokenStream.
In the ext folder of the Jinja2 source distribution there is a file
called inlinegettext.py which implements a filter that utilizes this
method.
If any of the tags matched this method is called with the
parser as first argument. The token the parser stream is pointing at
is the name token that matched. This method has to return one or a
list of multiple nodes.
The filename of the template the parser processes. This is not
the load name of the template. For the load name see name.
For templates that were not loaded form the file system this is
None.
Parse an expression. Per default all expressions are parsed, if
the optional with_condexpr parameter is set to False conditional
expressions are not parsed.
Works like parse_expression but if multiple expressions are
delimited by a comma a Tuple node is created.
This method could also return a regular expression instead of a tuple
if no commas where found.
The default parsing mode is a full tuple. If simplified is True
only names and literals are parsed. The no_condexpr parameter is
forwarded to parse_expression().
Because tuples do not require delimiters and may end in a bogus comma
an extra hint is needed that marks the end of a tuple. For example
for loops support tuples between for and in. In that case the
extra_end_rules is set to ['name:in'].
explicit_parentheses is true if the parsing was triggered by an
expression in parentheses. This is used to figure out if an empty
tuple is a valid expression or not.
Parse an assignment target. As Jinja2 allows assignments to
tuples, this function can parse all allowed assignment targets. Per
default assignments to tuples are parsed, that can be disable however
by setting with_tuple to False. If only assignments to names are
wanted name_only can be set to True. The extra_end_rules
parameter is forwarded to the tuple parsing function.
Parse multiple statements into a list until one of the end tokens
is reached. This is used to parse the body of statements as it also
parses template data if appropriate. The parser checks first if the
current token is a colon and skips it if there is one. Then it checks
for the block end and parses until if one of the end_tokens is
reached. Per default the active token in the stream at the end of
the call is the matched end token. If this is not wanted drop_needle
can be set to True and the end token is removed.
Convenience method that raises exc with the message, passed
line number or last line number as well as the current name and
filename.
class jinja2.lexer.TokenStream(generator, name, filename)¶
A token stream is an iterable that yields Tokens. The
parser however does not iterate over it but calls next() to go
one token ahead. The current active token is stored as current.
Test a token against a token expression. This can either be a
token type or 'token_type:token_value'. This can only test
against string values and types.
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.
All nodes have fields and attributes. Fields may be other nodes, lists,
or arbitrary values. Fields are passed to the constructor as regular
positional arguments, attributes as keyword arguments. Each node has
two attributes: lineno (the line number of the node) and environment.
The environment attribute is set at the end of the parsing process for
all nodes automatically.
Iterates over all direct child nodes of the node. This iterates
over all fields and yields the values of they are nodes. If the value
of a field is a list all the nodes in that list are returned.
This method iterates over all fields that are defined and yields
(key,value) tuples. Per default all fields are returned, but
it’s possible to limit that to some fields by providing the only
parameter or to exclude some using the exclude parameter. Both
should be sets or tuples of field names.
Reset the context of a node and all child nodes. Per default the
parser will all generate nodes that have a ‘load’ context as it’s the
most common one. This method is used in the parser to set assignment
targets and other nodes to a store context.
class jinja2.nodes.Call(node, args, kwargs, dyn_args, dyn_kwargs)¶
Calls an expression. args is a list of arguments, kwargs a list
of keyword arguments (list of Keyword nodes), and dyn_args
and dyn_kwargs has to be either None or a node that is used as
node for dynamic positional (*args) or keyword (**kwargs)
arguments.
If created with an import name the import name is returned on node
access. For example ImportedName('cgi.escape') returns the escape
function from the cgi module on evaluation. Imports are optimized by the
compiler so there is no need to assign them to local variables.
An internal name in the compiler. You cannot create these nodes
yourself but the parser provides a
free_identifier() method that creates
a new identifier for you. This identifier is not available from the
template and is not threated specially by the compiler.
All constant values. The parser will return this node for simple
constants such as 42 or "foo" but it can be used to store more
complex values such as lists too. Only constants with a safe
representation (objects where eval(repr(x))==x is true).
For loop unpacking and some other things like multiple arguments
for subscripts. Like for Name ctx specifies if the tuple
is used for loading the names or storing.
class jinja2.nodes.For(target, iter, body, else_, test, recursive)¶
The for loop. target is the target for the iteration (usually a
Name or Tuple), iter the iterable. body is a list
of nodes that are used as loop-body, and else_ a list of nodes for the
else block. If no else node exists it has to be an empty list.
For filtered nodes an expression can be stored as test, otherwise None.
class jinja2.nodes.FromImport(template, names, with_context)¶
A node that represents the from import tag. It’s important to not
pass unsafe names to the name attribute. The compiler translates the
attribute lookups directly into getattr calls and does not use the
subscript callback of the interface. As exported variables may not
start with double underscores (which the parser asserts) this is not a
problem for regular Jinja code, but if this node is used in an extension
extra care must be taken.
The list of names may contain tuples if aliases are wanted.
class jinja2.nodes.Macro(name, args, defaults, body)¶
A macro definition. name is the name of the macro, args a list of
arguments and defaults a list of defaults if there are any. body is
a list of nodes for the macro body.
