--- /dev/null
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS =
+SPHINXBUILD = sphinx-build
+PAPER =
+
+# Internal variables.
+PAPEROPT_a4 = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS = -d _build/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help clean html web pickle htmlhelp latex changes linkcheck
+
+help:
+ @echo "Please use \`make <target>' where <target> is one of"
+ @echo " html to make standalone HTML files"
+ @echo " pickle to make pickle files (usable by e.g. sphinx-web)"
+ @echo " htmlhelp to make HTML files and a HTML help project"
+ @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+ @echo " changes to make an overview over all changed/added/deprecated items"
+ @echo " linkcheck to check all external links for integrity"
+
+clean:
+ -rm -rf _build/*
+
+html:
+ mkdir -p _build/html _build/doctrees
+ $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) _build/html
+ @echo
+ @echo "Build finished. The HTML pages are in _build/html."
+
+pickle:
+ mkdir -p _build/pickle _build/doctrees
+ $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) _build/pickle
+ @echo
+ @echo "Build finished; now you can process the pickle files or run"
+ @echo " sphinx-web _build/pickle"
+ @echo "to start the sphinx-web server."
+
+web: pickle
+
+htmlhelp:
+ mkdir -p _build/htmlhelp _build/doctrees
+ $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) _build/htmlhelp
+ @echo
+ @echo "Build finished; now you can run HTML Help Workshop with the" \
+ ".hhp project file in _build/htmlhelp."
+
+latex:
+ mkdir -p _build/latex _build/doctrees
+ $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) _build/latex
+ @echo
+ @echo "Build finished; the LaTeX files are in _build/latex."
+ @echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
+ "run these through (pdf)latex."
+
+changes:
+ mkdir -p _build/changes _build/doctrees
+ $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) _build/changes
+ @echo
+ @echo "The overview file is in _build/changes."
+
+linkcheck:
+ mkdir -p _build/linkcheck _build/doctrees
+ $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) _build/linkcheck
+ @echo
+ @echo "Link check complete; look for any errors in the above output " \
+ "or in _build/linkcheck/output.txt."
--- /dev/null
+# -*- coding: utf-8 -*-
+#
+# Jinja2 documentation build configuration file, created by
+# sphinx-quickstart on Sun Apr 27 21:42:41 2008.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# The contents of this file are pickled, so don't put values in the namespace
+# that aren't pickleable (module imports are okay, they're removed automatically).
+#
+# All configuration values have a default value; values that are commented out
+# serve to show the default value.
+
+import sys, os
+
+# If your extensions are in another directory, add it here. If the directory
+# is relative to the documentation root, use os.path.abspath to make it
+# absolute, like shown here.
+#sys.path.append(os.path.abspath('some/directory'))
+
+# General configuration
+# ---------------------
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+#extensions = []
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General substitutions.
+project = 'Jinja2'
+copyright = '2008, Armin Ronacher'
+
+# The default replacements for |version| and |release|, also used in various
+# other places throughout the built documents.
+#
+# The short X.Y version.
+version = '2.0'
+# The full version, including alpha/beta/rc tags.
+release = '2.0'
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+today_fmt = '%B %d, %Y'
+
+# List of documents that shouldn't be included in the build.
+#unused_docs = []
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+
+# Options for HTML output
+# -----------------------
+
+# The style sheet to use for HTML and HTML Help pages. A file of that name
+# must exist either in Sphinx' static/ path, or in one of the custom paths
+# given in html_static_path.
+html_style = 'default.css'
+
+# The name for this set of Sphinx documents. If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_use_modindex = True
+
+# If true, the reST sources are included in the HTML build as _sources/<name>.
+#html_copy_source = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.
+#html_use_opensearch = False
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'Jinja2doc'
+
+
+# Options for LaTeX output
+# ------------------------
+
+# The paper size ('letter' or 'a4').
+#latex_paper_size = 'letter'
+
+# The font size ('10pt', '11pt' or '12pt').
+#latex_font_size = '10pt'
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, document class [howto/manual]).
+latex_documents = [
+ ('index', 'Jinja2.tex', 'Jinja2 Documentation', 'Armin Ronacher', 'manual'),
+]
+
+# Additional stuff for the LaTeX preamble.
+#latex_preamble = ''
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_use_modindex = True
+++ /dev/null
-#!/usr/bin/env python
-# -*- coding: utf-8 -*-
-"""
- Generate Jinja Documentation
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
- Generates a bunch of html files containing the documentation.
-
- :copyright: 2006-2007 by Armin Ronacher, Georg Brandl.
- :license: BSD, see LICENSE for more details.
-"""
-import os
-import sys
-sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..'))
-import re
-import inspect
-from datetime import datetime
-from cgi import escape
-
-from docutils import nodes
-from docutils.parsers.rst import directives
-from docutils.core import publish_parts
-from docutils.writers import html4css1
-
-from jinja import Environment
-
-from pygments import highlight
-from pygments.lexers import get_lexer_by_name
-from pygments.formatters import HtmlFormatter
-
-def generate_list_of_filters():
- from jinja.filters import FILTERS
- result = []
-
- filters = {}
- for name, f in FILTERS.iteritems():
- if not f in filters:
- filters[f] = ([name], inspect.getdoc(f))
- else:
- filters[f][0].append(name)
- for names, _ in filters.itervalues():
- names.sort(key=lambda x: -len(x))
-
- for names, doc in sorted(filters.values(), key=lambda x: x[0][0].lower()):
- name = names[0]
- if len(names) > 1:
- aliases = '\n\n :Aliases: %s\n' % ', '.join(names[1:])
- else:
- aliases = ''
-
- doclines = []
- for line in doc.splitlines():
- doclines.append(' ' + line)
- doc = '\n'.join(doclines)
- result.append('`%s`\n%s%s' % (name, doc, aliases))
-
- return '\n'.join(result)
-
-def generate_list_of_tests():
- from jinja.tests import TESTS
- result = []
-
- tests = {}
- for name, f in TESTS.iteritems():
- if not f in tests:
- tests[f] = ([name], inspect.getdoc(f))
- else:
- tests[f][0].append(name)
- for names, _ in tests.itervalues():
- names.sort(key=lambda x: -len(x))
-
- for names, doc in sorted(tests.values(), key=lambda x: x[0][0].lower()):
- name = names[0]
- if len(names) > 1:
- aliases = '\n\n :Aliases: %s\n' % ', '.join(names[1:])
- else:
- aliases = ''
-
- doclines = []
- for line in doc.splitlines():
- doclines.append(' ' + line)
- doc = '\n'.join(doclines)
- result.append('`%s`\n%s%s' % (name, doc, aliases))
-
- return '\n'.join(result)
-
-def generate_list_of_loaders():
- from jinja import loaders as loader_module
-
- result = []
- loaders = []
- for item in loader_module.__all__:
- loaders.append(getattr(loader_module, item))
- loaders.sort(key=lambda x: x.__name__.lower())
-
- for loader in loaders:
- doclines = []
- for line in inspect.getdoc(loader).splitlines():
- doclines.append(' ' + line)
- result.append('`%s`\n%s' % (loader.__name__, '\n'.join(doclines)))
-
- return '\n\n'.join(result)
-
-def generate_list_of_baseloaders():
- from jinja import loaders as loader_module
-
- result = []
- loaders = []
- for item in dir(loader_module):
- obj = getattr(loader_module, item)
- try:
- if issubclass(obj, loader_module.BaseLoader) and \
- obj.__name__ != 'BaseLoader' and \
- obj.__name__ not in loader_module.__all__:
- loaders.append(obj)
- except TypeError:
- pass
- loaders.sort(key=lambda x: x.__name__.lower())
-
- for loader in loaders:
- doclines = []
- for line in inspect.getdoc(loader).splitlines():
- doclines.append(' ' + line)
- result.append('`%s`\n%s' % (loader.__name__, '\n'.join(doclines)))
-
- return '\n\n'.join(result)
-
-def generate_environment_doc():
- from jinja.environment import Environment
- return '%s\n\n%s' % (
- inspect.getdoc(Environment),
- inspect.getdoc(Environment.__init__)
- )
-
-e = Environment()
-
-PYGMENTS_FORMATTER = HtmlFormatter(style='pastie', cssclass='syntax')
-
-LIST_OF_FILTERS = generate_list_of_filters()
-LIST_OF_TESTS = generate_list_of_tests()
-LIST_OF_LOADERS = generate_list_of_loaders()
-LIST_OF_BASELOADERS = generate_list_of_baseloaders()
-ENVIRONMENT_DOC = generate_environment_doc()
-CHANGELOG = file(os.path.join(os.path.dirname(__file__), os.pardir, 'CHANGES'))\
- .read().decode('utf-8')
-
-FULL_TEMPLATE = e.from_string('''\
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <title>{{ title }} — Jinja Documentation</title>
- <meta http-equiv="content-type" content="text/html; charset=utf-8">
- <link rel="stylesheet" href="style.css" type="text/css">
- <style type="text/css">
- {{ style|e }}
- </style>
-</head>
-<body>
- <div id="content">
- {% if file_id == 'index' %}
- <div id="jinjalogo"></div>
- <h2 class="subheading plain">{{ title }}</h2>
- {% else %}
- <h1 class="heading"><span>Jinja</span></h1>
- <h2 class="subheading">{{ title }}</h2>
- {% endif %}
- {% if file_id != 'index' or toc %}
- <div id="toc">
- <h2>Navigation</h2>
- <ul>
- <li><a href="index.html">back to index</a></li>
- </ul>
- {% if toc %}
- <h2>Contents</h2>
- <ul class="contents">
- {% for key, value in toc %}
- <li><a href="{{ key }}">{{ value }}</a></li>
- {% endfor %}
- </ul>
- {% endif %}
- </div>
- {% endif %}
- <div id="contentwrapper">
- {{ body }}
- </div>
- </div>
-</body>
-<!-- generated on: {{ generation_date }}
- file id: {{ file_id }} -->
-</html>\
-''')
-
-PREPROC_TEMPLATE = e.from_string('''\
-<!-- TITLE -->{{ title }}<!-- ENDTITLE -->
-<!-- TOC -->{% for key, value in toc %}<li><a href="{{
- key }}">{{ value }}</a></li>{% endfor %}<!-- ENDTOC -->
-<!-- BODY -->{{ body }}<!-- ENDBODY -->\
-''')
-
-def pygments_directive(name, arguments, options, content, lineno,
- content_offset, block_text, state, state_machine):
- try:
- lexer = get_lexer_by_name(arguments[0])
- except ValueError:
- # no lexer found
- lexer = get_lexer_by_name('text')
- parsed = highlight(u'\n'.join(content), lexer, PYGMENTS_FORMATTER)
- return [nodes.raw('', parsed, format="html")]
-pygments_directive.arguments = (1, 0, 1)
-pygments_directive.content = 1
-directives.register_directive('sourcecode', pygments_directive)
-
-
-def create_translator(link_style):
- class Translator(html4css1.HTMLTranslator):
- def visit_reference(self, node):
- refuri = node.get('refuri')
- if refuri is not None and '/' not in refuri and refuri.endswith('.txt'):
- node['refuri'] = link_style(refuri[:-4])
- html4css1.HTMLTranslator.visit_reference(self, node)
- return Translator
-
-
-class DocumentationWriter(html4css1.Writer):
-
- def __init__(self, link_style):
- html4css1.Writer.__init__(self)
- self.translator_class = create_translator(link_style)
-
- def translate(self):
- html4css1.Writer.translate(self)
- # generate table of contents
- contents = self.build_contents(self.document)
- contents_doc = self.document.copy()
- contents_doc.children = contents
- contents_visitor = self.translator_class(contents_doc)
- contents_doc.walkabout(contents_visitor)
- self.parts['toc'] = self._generated_toc
-
- def build_contents(self, node, level=0):
- sections = []
- i = len(node) - 1
- while i >= 0 and isinstance(node[i], nodes.section):
- sections.append(node[i])
- i -= 1
- sections.reverse()
- toc = []
- for section in sections:
- try:
- reference = nodes.reference('', '', refid=section['ids'][0], *section[0])
- except IndexError:
- continue
- ref_id = reference['refid']
- text = escape(reference.astext().encode('utf-8'))
- toc.append((ref_id, text))
-
- self._generated_toc = [('#%s' % href, caption) for href, caption in toc]
- # no further processing
- return []
-
-
-def generate_documentation(data, link_style):
- writer = DocumentationWriter(link_style)
- data = data.replace('[[list_of_filters]]', LIST_OF_FILTERS)\
- .replace('[[list_of_tests]]', LIST_OF_TESTS)\
- .replace('[[list_of_loaders]]', LIST_OF_LOADERS)\
- .replace('[[list_of_baseloaders]]', LIST_OF_BASELOADERS)\
- .replace('[[environment_doc]]', ENVIRONMENT_DOC)\
- .replace('[[changelog]]', CHANGELOG)
- parts = publish_parts(
- data,
- writer=writer,
- settings_overrides={
- 'initial_header_level': 2,
- 'field_name_limit': 50,
- }
- )
- return {
- 'title': parts['title'].encode('utf-8'),
- 'body': parts['body'].encode('utf-8'),
- 'toc': parts['toc']
- }
-
-
-def handle_file(filename, fp, dst, preproc):
- now = datetime.now()
- title = os.path.basename(filename)[:-4]
- content = fp.read().decode('utf-8')
- suffix = not preproc and '.html' or ''
- parts = generate_documentation(content, (lambda x: './%s%s' % (x, suffix)))
- result = file(os.path.join(dst, title + '.html'), 'w')
- c = dict(parts)
- c['style'] = PYGMENTS_FORMATTER.get_style_defs('.syntax')
- c['generation_date'] = now
- c['file_id'] = title
- if preproc:
- tmpl = PREPROC_TEMPLATE
- else:
- tmpl = FULL_TEMPLATE
- result.write(tmpl.render(c).encode('utf-8'))
- result.close()
-
-
-def run(dst, preproc, sources=(), handle_file=handle_file):
- path = os.path.abspath(os.path.join(os.path.dirname(__file__), 'src'))
- if not sources:
- sources = [os.path.join(path, fn) for fn in os.listdir(path)]
- for fn in sources:
- if not os.path.isfile(fn):
- continue
- print 'Processing %s' % fn
- f = open(fn)
- try:
- handle_file(fn, f, dst, preproc)
- finally:
- f.close()
-
-
-def main(dst='html/', preproc=False, *sources):
- run(os.path.realpath(dst), str(preproc).lower() == 'true', sources)
-
-
-if __name__ == '__main__':
- main(*sys.argv[1:])
+++ /dev/null
-body {
- background-color: #333;
- margin: 0;
- padding: 0;
- font-family: 'Georgia', serif;
- font-size: 15px;
- color: #111;
-}
-
-#content {
- background-color: white;
- background-image: url(watermark.png);
- padding: 10px;
- margin: 25px;
- border: 4px solid #ddd;
-}
-
-h1 {
- margin: 0;
- padding: 0;
- height: 80px;
- background-image: url(jinjabanner.png);
- background-repeat: no-repeat;
-}
-
-h1 span {
- display: none;
-}
-
-h2.subheading {
- margin: -55px 0 35px 200px;
- font-weight: normal;
- font-size: 30px;
- color: #444;
-}
-
-h2.plain {
- margin: 0;
-}
-
-#jinjalogo {
- background-image: url(jinjalogo.png);
- background-repeat: no-repeat;
- width: 400px;
- height: 160px;
-}
-
-#contentwrapper {
- max-width: 700px;
- padding: 0 0 20px 18px;
-}
-
-#contentwrapper h3,
-#contentwrapper h3 a {
- color: #b41717;
- font-size: 26px;
- margin: 20px 0 0 -5px;
-}
-
-#contentwrapper h4,
-#contentwrapper h4 a {
- color: #b41717;
- font-size: 20px;
- margin: 20px 0 0 0;
-}
-
-table.docutils {
- border-collapse: collapse;
- border: 2px solid #aaa;
- margin: 0.5em 1.5em 0.5em 1.5em;
-}
-
-table.docutils td {
- padding: 2px;
- border: 1px solid #ddd;
-}
-
-p, li, dd, dt, blockquote {
- color: #333;
-}
-
-p {
- line-height: 150%;
- margin-bottom: 0;
- margin-top: 10px;
- text-align: justify;
-}
-
-hr {
- border-top: 1px solid #ccc;
- border-bottom: 0;
- border-right: 0;
- border-left: 0;
- margin-bottom: 10px;
- margin-top: 20px;
-}
-
-dl {
- margin-left: 10px;
-}
-
-li, dt {
- margin-top: 5px;
-}
-
-dt {
- font-weight: bold;
-}
-
-th {
- text-align: left;
- padding: 3px;
- background-color: #f2f2f2;
-}
-
-a {
- color: #b41717;
-}
-
-a:hover {
- color: #444;
-}
-
-pre {
- background-color: #f9f9f9;
- border-top: 1px solid #ccc;
- border-bottom: 1px solid #ccc;
- padding: 5px;
- font-size: 13px;
- font-family: 'Bitstream Vera Sans Mono', 'Monaco', monospace;
-}
-
-tt {
- font-size: 13px;
- font-family: 'Bitstream Vera Sans Mono', 'Monaco', monospace;
- color: black;
- padding: 1px 2px 1px 2px;
- background-color: #f0f0f0;
-}
-
-cite {
- /* abusing <cite>, it's generated by ReST for `x` */
- font-size: 13px;
- font-family: 'Bitstream Vera Sans Mono', 'Monaco', monospace;
- font-weight: bold;
- font-style: normal;
-}
-
-div.admonition {
- margin: 10px 0 10px 0;
- padding: 10px;
- border: 1px solid #ccc;
- background-color: #f8f8f8;
-}
-
-div.admonition p.admonition-title {
- margin: -3px 0 5px 0;
- font-weight: bold;
- color: #b41717;
- font-size: 16px;
-}
-
-div.admonition p {
- margin: 0 0 0 40px;
-}
-
-#toc {
- margin: 0 -10px 10px 15px;
- padding: 10px;
- width: 200px;
- float: right;
- background-color: #f8f8f8;
- border: 1px solid #ccc;
- border-right: none;
-}
-
-#toc h2 {
- font-size: 20px;
- margin: 0 0 10px 0;
- padding: 0;
- color: #444;
-}
-
-#toc ul {
- margin: 0 0 0 30px;
- padding: 0;
-}
-
-#toc ul + h2 {
- margin-top: 10px;
-}
-
-#toc ul li {
- padding: 0;
- margin: 2px 0 2px 0;
-}
--- /dev/null
+.. Jinja2 documentation master file, created by sphinx-quickstart on Sun Apr 27 21:42:41 2008.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Welcome to Jinja2's documentation!
+==================================
+
+Contents:
+
+.. toctree::
+ :maxdepth: 2
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
+
+++ /dev/null
-==================
-Alternative Syntax
-==================
-
-Jinja allows some syntax customization for the block delimiters. Depending on
-the Jinja release more or less combinations are possible. The idea of an
-customizable syntax is that you can update existing templates from other
-template engines and programming languages easier and that you can replace
-the django like default delimiters which are not everybody's favorite.
-
-
-Configuring The Environment
-===========================
-
-For syntax configuration there are six arguments in the environment which
-are the first six for convenience. Thus those two snippets do the same:
-
-.. sourcecode:: python
-
- env = Environment(
- block_start_string='{%',
- block_end_string='%}',
- variable_start_string='{{',
- variable_end_string='}}',
- comment_start_string='{#',
- comment_end_string='#}',
- )
-
- env = Environment('{%', '%}', '{{', '}}', '{#', '#]')
-
-
-Ruby Like Syntax
-----------------
-
-Here an example configuration for Ruby-like syntax:
-
-.. sourcecode:: python
-
- env = Environment('<%', '%>', '<%=', '%>', '<%#', '%>')
-
-An example template then looks like this:
-
-.. sourcecode:: rhtml
-
- <%# example eruby like configuration for Jinja %>
- <ul>
- <% for item in seq %>
- <li><%= item %></li>
- <% endâ€for %>
- </ul>
-
-
-SGML Comment Syntax
--------------------
-
-Here an example configuration that uses SGML comments to hide the
-processing instructions. This can be useful if you work with an WYSIWYG
-designer:
-
-.. sourcecode:: python
-
- env = Environment('<!--', '-->', '${', '}', '<!--#', '-->')
-
-.. sourcecode:: html
-
- <!--# example SGML comment configuration for Jinja -->
- <ul>
- <!-- for item in seq -->
- <li>${item}</li>
- <!-- endfor -->
- </ul>
-
-
-Parenthesis Balancing
----------------------
-
-Starting with Jinja 1.1 it's possible to use the block delimiter as a token
-in the expression. That means that you can use small delimiters like single
-braces or parenthesis. So if you want to have your variables to look like
-``${expr}`` and you still want to use dicts in such expressions you need
-Jinja 1.1 or higher.
-
-
-Block / Variable Tag Unification
-================================
-
-If variable end and start tags are `None` or look the same as block tags and
-you're running Jinja 1.1 or later the parser will switch into the
-`no_comment_block` mode. In that mode it will try to match something as block
-first and continue treating it as variable block if there is no known
-directive for that name. Example:
-
-.. sourcecode:: python
-
- env = Environment('{', '}', None, None, '{*', '*}')
-
-This now allows smarty like templates:
-
-.. sourcecode:: smarty
-
- {* example smarty-like configuration for Jinja *}
- {if something == 42}
- Something is the answer to all questions and stuff like that.
- {else}
- Something is {something}.
- {endif}
-
-This feature however can cause strange looking templates because there is no
-visible difference between blocks and variables.
+++ /dev/null
-=======================
-Context and Environment
-=======================
-
-The two central objects in Jinja are the `Environment` and `Context`. Both
-are designed to be subclassed by applications if they need to extend Jinja.
-
-Environment
-===========
-
-The initialization parameters are already covered in the `Quickstart`_ thus
-not repeated here.
-
-But beside those configurable instance variables there are some functions used
-in the template evaluation code you may want to override:
-
-**def** `parse` *(source, filename)*:
-
- Parse the sourcecode and return the abstract syntax tree. This tree of
- nodes is used by the `translators`_ to convert the template into
- executable source- or bytecode.
-
-**def** `lex` *(source, filename)*:
-
- Tokenize the given sourcecode and return a generator of tuples in the
- form ``(lineno, token, value)``. The filename is just used in the
- exceptions raised.
-
- **New in Jinja 1.1**
-
-**def** `from_string` *(source)*:
-
- Load and parse a template source and translate it into eval-able Python
- code. This code is wrapped within a `Template` class that allows you to
- render it.
-
-**def** `get_template` *(name)*:
-
- Load a template from a loader. If the template does not exist, you will
- get a `jinja.exceptions.TemplateNotFound` exception.
-
-**def** `to_unicode` *(self, value)*:
-
- Called to convert variables to unicode. Per default this checks if the
- value is already unicode. If not it's converted to unicode using the
- charset defined on the environment.
-
- Also `None` is converted into an empty string per default.
-
-**def** `get_translator` *(self, context)*:
-
- Return the translator used for i18n. A translator is an object that
- provides the two functions ``gettext(string)`` and
- ``ngettext(singular, plural, n)``. Both of those functions have to
- behave like the `ugettext` and `nugettext` functions described in the
- python `gettext documentation`_.
-
- If you don't provide a translator a default one is used to switch
- between singular and plural forms.
-
- Have a look at the `i18n`_ section for more information.
-
-**def** `get_translations` *(self, name)*:
-
- Get the translations for the template `name`. Only works if a loader
- is present. See the `i18n`_ section for more details.
-
-**def** `get_translations_for_string` *(self, string)*:
-
- Get the translations for the string `string`. This works also if no
- loader is present and can be used to lookup translation strings from
- templates that are loaded from dynamic resources like databases.
-
-**def** `apply_filters` *(self, value, context, filters)*:
-
- Now this function is a bit tricky and you usually don't have to override
- it. It's used to apply filters on a value. The Jinja expression
- ``{{ foo|escape|replace('a', 'b') }}`` calls the function with the
- value of `foo` as first parameter, the current context as second and
- a list of filters as third. The list looks like this:
-
- .. sourcecode:: python
-
- [('escape', ()), ('replace', (u'a', u'b'))]
-
- As you can see the filter `escape` is called without arguments whereas
- `replace` is called with the two literal strings ``a`` and ``b``, both
- unicode. The filters for the names are stored on ``self.filters`` in a
- dict. Missing filters should raise a `FilterNotFound` exception.
-
- **Warning** this is a Jinja internal method. The actual implementation
- and function signature might change.
-
-**def** `perform_test` *(self, context, testname, args, value, invert)*:
-
- Like `apply_filters` you usually don't override this one. It's the
- callback function for tests (``foo is bar`` / ``foo is not bar``).
-
- The first parameter is the current contex, the second the name of
- the test to perform. the third a tuple of arguments, the fourth is
- the value to test. The last one is `True` if the test was performed
- with the `is not` operator, `False` if with the `is` operator.
-
- Missing tests should raise a `TestNotFound` exception.
-
- **Warning** this is a Jinja internal method. The actual implementation
- and function signature might change.
-
-**def** `get_attribute` *(self, obj, attribute)*:
-
- Get `attribute` from the object provided. The default implementation
- performs security tests.
-
- **Warning** this is a Jinja internal method. The actual implementation
- and function signature might change.
-
-**def** `get_attributes` *(self, obj, attributes)*:
-
- Get some attributes from the object. If `attributes` is an empty
- sequence the object itself is returned unchanged.
-
-**def** `call_function` *(self, f, context, args, kwargs, dyn_args, dyn_kwargs)*:
-
- Call a function `f` with the arguments `args`, `kwargs`, `dyn_args` and
- `dyn_kwargs` where `args` is a tuple and `kwargs` a dict. If `dyn_args`
- is not `None` you have to add it to the arguments, if `dyn_kwargs` is
- not `None` you have to update the `kwargs` with it.
-
- The default implementation performs some security checks.
-
- **Warning** this is a Jinja internal method. The actual implementation
- and function signature might change.
-
-**def** `call_function_simple` *(self, f, context)*:
-
- Like `call_function` but without arguments.
-
- **Warning** this is a Jinja internal method. The actual implementation
- and function signature might change.
-
-**def** `finish_var` *(self, value, ctx)*:
-
- Postprocess a variable before it's sent to the template.
-
- **Warning** this is a Jinja internal method. The actual implementation
- and function signature might change.
-
-.. admonition:: Note
-
- The Enviornment class is defined in `jinja.environment.Environment`
- but imported into the `jinja` package because it's often used.
-
-Context
-=======
-
-Jinja wraps the variables passed to the template in a special class called a
-context. This context supports variables on multiple layers and lazy (deferred)
-objects. Often your application has a request object, database connection
-object or something similar you want to access in filters, functions etc.
-
-The default context object is defined in `jinja.datastructure`. If you want
-to provide your own context object always subclass the default one. This
-ensures that the class continues working after Jinja upgrades.
-
-Beacause of that you can easily subclass a context to add additional variables
-or to change the way it behaves.
-
-**def** `pop` *(self)*:
-
- Pop the outermost layer and return it.
-
-**def** `push` *(self, data=None)*:
-
- Push a dict to the stack or an empty layer.
-
- Has to return the pushed object.
-
-**def** `to_dict` *(self)*:
-
- Flatten the context and convert it into a dict.
-
-**def** `__getitem__` *(self, name)*:
-
- Resolve an item. Per default this also resolves `Deferred` objects.
-
-**def** `__setitem__` *(self, name, value)*:
-
- Set an item in the outermost layer.
-
-**def** `__delitem__` *(self, name)*:
-
- Delete an item in the outermost layer. Do not raise exceptions if
- the value does not exist.
-
-**def** `__contains__` *(self, name)*:
-
- Return `True` if `name` exists in the context.
-
-**attribute** `cache`:
-
- The cache is a dict which can be used by filters, test functions
- and global objects to cache data. It's also used by the environment
- to cache often used tests and filters.
-
-**attribute** `translate_func`:
-
- This property is created on first access and returns a translation
- function used by the rendering process to translate strings with the
- translator defined on the environment.
-
-.. admonition:: Note
-
- The context uses a stack of dicts internally to represent the
- layers of variables. It contains at least 3 levels available on
- the context with some attributes. Those are:
-
- `globals`:
-
- The reference to the global namespace of the environment.
- It's the lowest namespace on the stack and thus immutable
-
- `initial`:
-
- The initial namespace. Contains the values passed to the
- context in the render function. It also contains the resolved
- deferred values for bot the `initial` and the `globals`
- namespace.
-
- `current`:
-
- The reference to the current active namespace. When the
- context is initialized this automatically points to an
- empty namespace.
-
- The number of layers on the stack are theoretically unlimited.
- Some elements in the template language like loops, blocks,
- macros and others push and pop the layer on entering and leaving
- the section.
-
- This is done in order to keep the namespace clean.
-
- Note that since Jinja 1.1 the context object is a subclass of the
- `BaseContext`, a much simpler class that just implements a stack
- like namespace for python. If the `_speedups` extension was
- compiled for jinja the base class will be
- `jinja._speedups.BaseContext` otherwise `jinja._native.BaseContext`.
-
- Since you cannot reproduce completely the same semantics in python
- and the C API there are some things you should keep in mind:
-
- - The `stack` attribute of the context maps to the real layers
- on the stack, thus you can modify the items but the list as
- such is meant to be read only.
-
- - `globals`, `current` and `initial` are read only attributes that
- map to layers on the stack which you can of course modify.
-
-
-Exceptions
-==========
-
-During parsing and evaluation Jinja raises a couple of Jinja specific
-exceptions. All of those exceptions are defined in the `jinja.exceptions`
-module and are subclasses of the `TemplateError` class defined there.
-
-Here a list of exceptions that could occur:
-
-`SecurityException`:
-
- An exception that is raised if the template tried to access something
- it should not access. In the default configuration this exception
- will get caught in the Jinja rendering process and silenced.
-
- If however the environment is configured to not silently fail it
- could happen that this exception reaches the application.
-
-`FilterNotFound`:
-
- Raised if the template tried to apply a filter that does not exist.
- Since this exception is a subclass of `KeyError` too you can catch
- it this way too.
-
-`FilterArgumentError`:
-
- Raised if the filter received an argument that it couldn't handle.
- It's a subclass of `TypeError` too so you can catch it this way too.
-
-`TestNotFound`:
-
- Raised if the template tried to perform a test that does not exist.
- Since this exception is a subclass of `KeyError` too you can catch
- it this way too.
-
-`TestArgumentError`:
-
- Raised if a test function received an argument that it couldn't handle.
- It's a subclass of `TypeError` too so you can catch it this way too.
-
-`TemplateNotFound`:
-
- Raised if a template does not exist. Subclass of `IOError` too.
-
-`TemplateSyntaxError`:
-
- Subclass of `SyntaxError` and used to indicate an syntax error.
-
-`TemplateRuntimeError`:
-
- Generic runtime error exception which can occour at various places.
-
-
-.. _i18n: i18n.txt
-.. _translators: translators.txt
-.. _Quickstart: devintro.txt
-.. _gettext documentation: http://docs.python.org/lib/module-gettext.html
+++ /dev/null
-===================================
-Filters, Tests and Helper Functions
-===================================
-
-This part of the documentation lists the filter-, test- and helper functions
-you can use in templates.
-
-
-Filters
-=======
-
-In the examples above you might have noticed the pipe symbols. Pipe symbols tell
-the engine that it has to apply a filter on the variable. Here is a small example:
-
-.. sourcecode:: jinja
-
- {{ variable|replace('foo', 'bar')|escape }}
-
-If you want, you can also put whitespace between the filters.
-
-This will look for a variable `variable`, pass it to the filter `replace`
-with the arguments ``'foo'`` and ``'bar'``, and pass the result to the filter
-`escape` that automatically XML-escapes the value. The `e` filter is an alias for
-`escape`. Here is the complete list of supported filters:
-
-[[list_of_filters]]
-
-.. admonition:: note
-
- *Jinja 1.0 and 1.1 notice*
-
- The filter operator has a pretty low priority in Jinja 1.0 and 1.1. If you
- want to add fitered values you have to put them into parentheses. The same
- applies if you want to access attributes or return values:
-
- .. sourcecode:: jinja
-
- correct:
- {{ (foo|filter) + (bar|filter) }}
- wrong:
- {{ foo|filter + bar|filter }}
-
- correct:
- {{ (foo|filter).attribute }}
- wrong:
- {{ foo|filter.attribute }}
-
- This changed in Jinja 1.2, from that version one the filter operator has
- the highest priority so you can do ``foo|filter + bar|filter``.
-
-*new in Jinja 1.1*:
-
-Because the application can provide additional filters you can get a documentation
-of all the provided filters by calling ``debug.filters()``:
-
-.. sourcecode:: jinja
-
- {{ debug.filters() }}
- -> returns a plain text representation of all the filters
-
- {{ debug.filters(False) }}
- -> same as above but without the builtin ones.
-
-Tests
-=====
-
-You can use the `is` operator to perform tests on a value:
-
-.. sourcecode:: jinja
-
- {{ 42 is numeric }} -> true
- {{ "foobar" is numeric }} -> false
- {{ 'FOO' is upper }} -> true
-
-These tests are especially useful when used in `if` conditions.
-
-[[list_of_tests]]
-
-*new in Jinja 1.1*:
-
-Because the application can provide additional tests you can get a documentation
-of all the provided tests by calling ``debug.tests()``:
-
-.. sourcecode:: jinja
-
- {{ debug.tests() }}
- -> returns a plain text representation of all the tests
-
- {{ debug.tests(False) }}
- -> same as above but without the builtin ones.
-
-*new in Jinja 1.2*:
-
-If a test function expects one or no argument you can leave out the parentheses.
-Previously this was only possible for text functions without arguments:
-
-.. sourcecode:: jinja
-
- {{ foo is matching @/\s+/ }}
- is the same as
- {{ foo is matching(@/\s+/) }}
-
-
-Global Functions
-================
-
-Test functions and filter functions live in their own namespace. Global
-functions not. They behave like normal objects in the context. Beside the
-functions added by the application or framewhere there are two functions
-available per default:
-
-`range`
-
- Works like the python `range function`_ just that it doesn't support
- ranges greater than ``1000000``.
-
-`debug`
-
- Function that outputs the contents of the context.
-
-`lipsum`
-
- Generate some paragraphs of random text:
-
- .. sourcecode:: jinja
-
- {{ lipsum(5) }}
- five html paragraphs
-
- {{ lipsum(2, False) }}
- two ascii only paragraphs
-
- Per default a paragraph is between 20 and 100 words long. You can
- override this default with the third and fourth parameter:
-
- .. sourcecode:: jinja
-
- {{ lipsum(10, True, 50, 200) }}
- generate 10 HTML paragraphs between 50 and 200 words.
-
- *new in Jinja 1.1*
-
-`watchchanges`
-
- Jinja does not provide an django like ``{% ifchanged %}`` tag. As
- replacement for this tag there is a special function in the namespace
- called `watchchanges`.
-
- You can use it like this:
-
- .. sourcecode:: html+jinja
-
- {% for changed, article in watchchanges(articles, 'date', 'day') %}
- {% if changed %}<h3>{{ articles.date.day }}</h3>{% endif %}
- <h4>{{ article.title|e }}</h4>
- <p>{{ article.body|e }}</p>
- {% endif %}
-
- For each iteration `watchchanges` will check the given attribute. If it
- changed to the former iteration the first yielded item (in this example
- it's called `changed`) will be `true`, else `false`.
-
- In this example `articles` is a list of articles for the template with
- an attribute called `date.day` which represents the current day. To only
- add a new day headline if the day has changed `watchchanges` is now told
- to check `articles.date.days`.
-
- If you want to observe more than one attribute you can provide pairs:
-
- .. sourcecode:: html+jinja
-
- {% for changed, item in watchchanges(foo, ('a', 'b'), ('a', 'c')) %}
- ...
- {% endfor %}
-
- Note that if you want to watch two first level attributes you have to
- either use the list syntax `[]` or add a colon:
-
- .. sourcecode:: html+jinja
-
- {% for changed, item in watchchanges(foo, ['a'], ('b',)) %}
- ...
- {% endfor %}
-
- otherwise Jinja cannot differ between a pair of parentheses to group
- expressions or the sequence syntax.
-
- If you don't provide any arguments the value of the variable itself
- is checked.
-
- *new in Jinja 1.1*
-
-`rendertemplate`
-
- Loads and renders a template with a copy of the current context. This works
- in many situations like the ``{% include %}`` tag, just that it does not
- include a template and merges it into the template structure but renders
- it completely independent and returns the rendered data as string.
-
- *new in Jinja 1.1*
-
-
-Global Constants
-================
-
-Jinja provides some special variables which cannot be overridden in templates.
-Those are not affected by the variable lookup:
-
- `_`, `true`, `false`, `none`, `undefined`
-
-You cannot use those names for your own variables or macros. It's however no
-problem to have blocks with that name.
-
-**Notice** due to a bug in Jinja 1.0 it was possible to override `_`, `true`,
-`false`, `none` and `undefined` from the template by either using `{% set %}`
-or in a for loop. While overriding `true`, `false` etc just caused nothing
-overriding the translation marker `_` would crash the translation interface.
-If you want to use `_` for unpacking in for loops (eg. skipping items) you
-have to give it a proper name:
-
-.. sourcecode:: jinja
-
- {% for key, ignore in mydict|dictsort %}
- {{ key|e }}
- {% endfor %}
-
-
-.. _range function: http://docs.python.org/tut/node6.html#SECTION006300000000000000000
+++ /dev/null
-[[changelog]]
+++ /dev/null
-===================
-Debugging Templates
-===================
-
-In order to keep templates debuggable you have to do some additional work on
-the application side. The traceback module that comes with python currently
-does not support the `__loader__` hook which is used by Jinja to provide
-templates. Although the import system was implemented three Python versions
-ago the default traceback system still doesn't support it.
-
-However most of the extended web development traceback modules have support
-for `__loader__`. Either directly or via the linecache module:
-
-- `Werkzeug Debugging Middleware`_
-- `Django`_
-- `cgitb`_
-- `EvalException`_
-
-To enable debugging you have to use one of those debugging systems or
-implement your own one with support for `__loader__`.
-
-The python implementation of the jinja debugger can only translate the first
-exception in a traceback which can lead to problematic results. If you have
-the extended debugger c extension compiled (default on unix systems but only
-available on Windows if you have a VisualStudio 2003 installation) all frames
-in the traceback will point to the correct linenumbers of the templates.
-
-
-.. _Werkzeug Debugging Middleware: http://werkzeug.pocoo.org/
-.. _Django: http://www.djangoproject.com/
-.. _cgitb: http://docs.python.org/lib/module-cgitb.html
-.. _EvalException: http://pythonpaste.org/module-paste.evalexception.html
+++ /dev/null
-======================
-Designer Documentation
-======================
-
-This part of the Jinja documentaton is meant for template designers.
-
-Basics
-======
-
-The Jinja template language is designed to strike a balance between content
-and application logic. Nevertheless you can use a python like statement
-language. You don't have to know how Python works to create Jinja templates,
-but if you know it you can use some additional statements you may know from
-Python.
-
-Here is a small example template:
-
-.. sourcecode:: html+jinja
-
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
- <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
- <head>
- <title>My Webpage</title>
- </head>
- <body>
- <ul id="navigation">
- {% for item in navigation %}
- <li><a href="{{ item.href|e }}">{{ item.caption|e }}</a></li>
- {% endfor %}
- </ul>
-
- <h1>My Webpage</h1>
- {{ variable }}
- </body>
- </html>
-
-This covers the default settings. The application developer might have changed
-the syntax from ``{% foo %}`` to ``<% foo %>`` or something similar. This
-documentation just covers the default values.
-
-A variable looks like ``{{ foobar }}`` where foobar is the variable name. Inside
-of statements (``{% some content here %}``) variables are just normal names
-without the braces around it. In fact ``{{ foobar }}`` is just an alias for
-the statement ``{% print foobar %}``.
-
-Variables are coming from the context provided by the application. Normally there
-should be a documentation regarding the context contents but if you want to know
-the content of the current context, you can add this to your template:
-
-.. sourcecode:: html+jinja
-
- <pre>{{ debug()|e }}</pre>
-
-A context isn't flat which means that each variable can has subvariables, as long
-as it is representable as python data structure. You can access attributes of
-a variable using the dot and bracket operators. The following examples show
-this:
-
-.. sourcecode:: jinja
-
- {{ user.username }}
- is the same as
- {{ user['username'] }}
- you can also use a variable to access an attribute:
- {{ users[current_user].username }}
- If you have numerical indices you have to use the [] syntax:
- {{ users[0].username }}
-
-*new in Jinja 1.2*: You can now use django like attributes for integer
-indices. Thus ``{{ foo.0 }}`` is equivalent to ``{{ foo[0] }}``.
-
-
-Loops
-=====
-
-To iterate over a sequence, you can use the `for` loop. It basically looks like a
-normal Python `for` loop and works pretty much the same:
-
-.. sourcecode:: html+jinja
-
- <h1>Members</h1>
- <ul>
- {% for user in users %}
- <li>{{ loop.index }} / {{ loop.length }} - {{ user.username|escape }}</li>
- {% else %}
- <li><em>no users found</em></li>
- {% endfor %}
- </ul>
-
-*Important* Contrary to Python is the optional `else` block only
-executed if there was no iteration because the sequence was empty.
-
-Inside of a `for` loop block you can access some special variables:
-
-+----------------------+----------------------------------------+
-| Variable | Description |
-+======================+========================================+
-| `loop.index` | The current iteration of the loop. |
-+----------------------+----------------------------------------+
-| `loop.index0` | The current iteration of the loop, |
-| | starting counting by 0. |
-+----------------------+----------------------------------------+
-| `loop.revindex` | The number of iterations from the end |
-| | of the loop. |
-+----------------------+----------------------------------------+
-| `loop.revindex0` | The number of iterations from the end |
-| | of the loop, starting counting by 0. |
-+----------------------+----------------------------------------+
-| `loop.first` | True if first iteration. |
-+----------------------+----------------------------------------+
-| `loop.last` | True if last iteration. |
-+----------------------+----------------------------------------+
-| `loop.even` | True if current iteration is even. |
-+----------------------+----------------------------------------+
-| `loop.odd` | True if current iteration is odd. |
-+----------------------+----------------------------------------+
-| `loop.length` | Total number of items in the sequence. |
-+----------------------+----------------------------------------+
-| `loop.parent` | The context of the parent loop. |
-+----------------------+----------------------------------------+
-
-Loops also support recursion. Let's assume you have a sitemap where each item
-might have a number of child items. A template for that could look like this:
-
-.. sourcecode:: html+jinja
-
- <h1>Sitemap
- <ul id="sitemap">
- {% for item in sitemap recursive %}
- <li><a href="{{ item.url|e }}">{{ item.title|e }}</a>
- {% if item.children %}<ul>{{ loop(item.children) }}</ul>{% endif %}</li>
- {% endfor %}
- </ul>
-
-What happens here? Basically the first thing that is different to a normal
-loop is the additional ``recursive`` modifier in the `for`-loop declaration.
-It tells the template engine that we want recursion. If recursion is enabled
-the special `loop` variable is callable. If you call it with a sequence it will
-automatically render the loop at that position with the new sequence as argument.
-
-Cycling
-=======
-
-Sometimes you might want to have different text snippets for each row in a list,
-for example to have alternating row colors. You can easily do this by using the
-``{% cycle %}`` tag:
-
-.. sourcecode:: html+jinja
-
- <ul id="messages">
- {% for message in messages %}
- <li class="{% cycle 'row1', 'row2' %}">{{ message|e }}</li>
- {% endfor %}
- </ul>
-
-Each time Jinja encounters a `cycle` tag it will cycle through the list
-of given items and return the next one. If you pass it one item jinja assumes
-that this item is a sequence from the context and uses this:
-
-.. sourcecode:: html+jinja
-
- <li style="color: {% cycle rowcolors %}">...</li>
-
-Conditions
-==========
-
-Jinja supports Python-like `if` / `elif` / `else` constructs:
-
-.. sourcecode:: jinja
-
- {% if user.active %}
- user {{ user.name|e }} is active.
- {% elif user.deleted %}
- user {{ user.name|e }} was deleted some time ago.
- {% else %}
- i don't know what's wrong with {{ user.username|e }}
- {% endif %}
-
-If the user is active the first block is rendered. If not and the user was
-deleted the second one, in all other cases the third one.
-
-You can also use comparison operators:
-
-.. sourcecode:: html+jinja
-
- {% if amount < 0 %}
- <span style="color: red">{{ amount }}</span>
- {% else %}
- <span style="color: black">{{ amount }}</span>
- {% endif %}
-
-.. admonition:: Note
-
- Of course you can use `or` / `and` and parentheses to create more complex
- conditions, but usually the logic is already handled in the application and
- you don't have to create such complex constructs in the template code. However
- in some situations it might be a good thing to have the abilities to create
- them.
-
-Literals
-========
-
-For most of the builtin python types, literals exist in Jinja. The following
-table shows which syntax elements are supported:
-
- ======================= ===================================================
- ``"text" / 'text'`` work like python's unicode literals (u'text').
- ``42`` integer literls.
- ``42.0`` float literals (exponents are not supported and
- before and after the dot digits must be present)
- ``[1, 'two', none]`` list literal
- ``(), (1,), (1, 2)`` tuple literals. (tuples work like lists but consume
- less memory and are not modifyable.)
- ``{'foo': 'bar'}`` dictionary literal
- ``@/expr/flags`` regular expression literals. ``@/expr/flags`` is
- equivalent to ``re.compile('(?flags)expr')`` in
- python.
- ``@(1, 2, 3)`` set literal. ``@(1, 2, 3)`` in Jinja is is equal to
- ``set([1, 2, 3])`` in python.
- ``true / false`` corresponds to `True` and `False` in python.
- ``none`` corresponds to `None` in python.
- ``undefined`` special Jinja undefined singleton.
- ======================= ===================================================
-
-.. admonition:: Common Pitfalls
-
- Keep in mind that Jinja literals, keywords and functions are all lowercase.
- If you're used to Python you probably tried to write `True` which evaluates
- to undefined because it simply does not exist. The correct name for the
- true value is just `true` (lowercase).
-
-
-Operators
-=========
-
-Inside ``{{ variable }}`` blocks, `if` conditions and many other parts you can
-can use expressions. In expressions you can use any of the following operators:
-
- ======= ===================================================================
- ``+`` add the right operand to the left one.
- ``{{ 1 + 2 }}`` would return ``3``.
- ``-`` subtract the right operand from the left one.
- ``{{ 1 - 1 }}`` would return ``0``.
- ``/`` divide the left operand by the right one.
- ``{{ 1 / 2 }}`` would return ``0.5``.
- ``//`` divide the left operand by the right one and return a truncated
- integer result: ``{{ 20 // 7 }}`` is ``2``.
- *added in Jinja 1.1*
- ``~`` string concatenate a value with another one. ``{{ foo ~ bar }}``
- is equivalent to ``{{Â foo|string + bar|string }}``. *added in
- Jinja 1.1*
- ``*`` multiply the left operand with the right one.
- ``{{ 2 * 2 }}`` would return ``4``.
- ``**`` raise the left operand to the power of the right
- operand. ``{{ 2**3 }}`` would return ``8``.
- ``%`` calculate the remainder of an integer division between the
- left and right operand: ``{{ 11 % 7 }}`` is ``4``.
- ``in`` perform sequence membership test. ``{{ 1 in [1,2,3] }}`` would
- return true.
- ``is`` perform a test on the value. See the section about
- tests for more information.
- ``|`` apply a filter on the value. See the section about
- filters for more information.
- ``and`` return true if the left and the right operand is true.
- ``or`` return true if the left or the right operand is true.
- ``not`` negate a statement (see below)
- ``()`` call a callable: ``{{ user.get_username() }}``. Inside of the
- parentheses you can use variables: ``{{ user.get(username) }}``.
- ======= ===================================================================
-
-Note that there is no support for any bit operations or something similar.
-
-* special note regarding `not`: The `is` and `in` operators support negation
- using an infix notation too: ``foo is not bar`` and ``foo not in bar``
- instead of ``not foo is bar`` and ``not foo in bar``. All other expressions
- require a prefix notation: ``not (foo and bar)``.
-
-
-With Jinja 1.2 onwards it's possible to replace basic if/else blocks with the
-inline `if` / `else` expression. The following two examples evaluate to the
-same:
-
-.. sourcecode:: jinja
-
- {{ "something" if expr else "otherthing" }}
-
- {% if expr %}something{% else %}otherthing{% endif %}
-
-
-Boolean Values
-==============
-
-In If-Conditions Jinja performs a boolean check. All empty values (eg: empty
-lists ``[]``, empty dicts ``{}`` etc) evaluate to `false`. Numbers that are
-equal to `0`/`0.00` are considered `false` too. The boolean value of other
-objects depends on the behavior the application developer gave it. Usually
-items are `true`.
-
-Here some examples that should explain it:
-
-.. sourcecode:: jinja
-
- {% if [] %}
- will always be false because it's an empty list
-
- {% if {} %}
- false too.
-
- {% if ['foo'] %}
- this is true. Because the list is not empty.
-
- {% if "foobar" %}
- this is also true because the string is not empty.
-
-Slicing
-=======
-
-Some objects support slicing operations. For example lists:
-
-.. sourcecode:: jinja
-
- {% for item in items[:5] %}
- This will only iterate over the first 5 items of the list
-
- {% for item in items[5:10] %}
- This will only iterate from item 5 to 10.
-
- {% for item in items[:10:2] %}
- This will only yield items from start to ten and only returing
- even items.
-
-For more informations about slicing have a look at the `slicing chapter`_
-in the "Dive into Python" e-book.
-
-Macros
-======
-
-If you want to use a partial template in more than one place, you might want to
-create a macro from it:
-
-.. sourcecode:: html+jinja
-
- {% macro show_user user %}
- <h1>{{ user.name|e }}</h1>
- <div class="text">
- {{ user.description }}
- </div>
- {% endmacro %}
-
-Now you can use it from everywhere in the code by passing it an item:
-
-.. sourcecode:: jinja
-
- {% for user in users %}
- {{ show_user(user) }}
- {% endfor %}
-
-You can also specify more than one value:
-
-.. sourcecode:: html+jinja
-
- {% macro show_dialog title, text %}
- <div class="dialog">
- <h1>{{ title|e }}</h1>
- <div class="text">{{ text|e }}</div>
- </div>
- {% endmacro %}
-
- {{ show_dialog('Warning', 'something went wrong i guess') }}
-
-*Improvements in Jinja 1.1*:
-
- Starting with Jinja 1.1 it's possible to use optional parentheses
- around the macro arguments:
-
- .. sourcecode:: html+jinja
-
- {% macro foo(a, b) %}
- ...
- {% endmacro %}
-
- Additionally extra arguments passed to the macro end up in the
- special variable `varargs`. So you can have a macro like this:
-
- .. sourcecode:: html+jinja
-
- {% macro make_list() %}
- {% if varargs %}
- <ul>
- {% for item in varargs %}
- <li>{{ item|e }}</li>
- {% endfor %}
- </ul>
- {% endif %}
- {% endmacro %}
-
- {{ make_list("John", "Jane", "Marcus", "Heinrich") }}
-
- If a macro parameter is called `varargs` the additional extra
- arguments are not accessible.
-
-For information regarding the visibility of macros have a look at the
-`Scopes and Variable Behavior`_ section.
-
-
-Extended Macro Call
-===================
-
-*new in Jinja 1.1*
-
-Jinja 1.1 adds a new special tag that you can use to pass some evaluable
-template code to a macro. Here an example macro that uses the features of
-the ``{% call %}`` tag:
-
-.. sourcecode:: html+jinja
-
- {% macro dialog title %}
- <div class="dialog">
- <h3>{{ title }}</h3>
- <div class="text">
- {{ caller() }}
- </div>
- </div>
- {% endmacro %}
-
-Called the normal way `caller` will be undefined, but if you call it
-using the new `{% call %}` tag you can pass it some data:
-
-.. sourcecode:: html+jinja
-
- {% call dialog('Hello World') %}
- This is an example dialog
- {% endcall %}
-
-Now the data wrapped will be inserted where you put the `caller` call.
-
-If you pass `caller()` some keyword arguments those are added to the
-namespace of the wrapped template data:
-
-.. sourcecode:: html+jinja
-
- {% macro makelist items %}
- <ul>
- {%- for item in items %}
- <li>{{ caller(item=item) }}</li>
- {%- endfor %}
- </ul>
- {%- endmacro %}
-
- {% call makelist([1, 2, 3, 4, 5, 6]) -%}
- [[{{ item }}]]
- {%- endcall %}
-
-This will then produce this output:
-
-.. sourcecode:: html
-
- <ul>
- <li>[[1]]</li>
- <li>[[2]]</li>
- <li>[[3]]</li>
- <li>[[4]]</li>
- <li>[[5]]</li>
- <li>[[6]]</li>
- </ul>
-
-
-Template Inclusion
-==================
-
-You can load another template at a given position using ``{% include %}``.
-Usually it's a better idea to use inheritance but if you for example want to
-load macros, `include` works better than `extends`:
-
-.. sourcecode:: jinja
-
- {% include "myhelpers.html" %}
- {{ my_helper("foo") }}
-
-If you define a macro called ``my_helper`` in ``myhelpers.html``, you can now
-use it from the template as shown above.
-
-Please keep in mind that include does not render the template indenpendently
-but includes the processing instructions into the current template. Thus if the
-included template contains a ``{% extends %}`` tag it also affects the current
-template.
-
-This is intended because it makes it possible to include macros from other
-templates.
-
-*new in Jinja 1.1* you can now render an included template to a string that is
-evaluated in an indepdendent environment by calling `rendertemplate`. See the
-documentation for this function in the `builtins`_ documentation.
-
-
-Filtering Blocks
-================
-
-Sometimes it could be a good idea to filter a complete block of text. For
-example, if you want to escape some html code:
-
-.. sourcecode:: jinja
-
- {% filter escape %}
- <html>
- <code>goes here</code>
- </html>
- {% endfilter %}
-
-Of course you can chain filters too:
-
-.. sourcecode:: jinja
-
- {% filter lower|escape %}
- <B>SOME TEXT</B>
- {% endfilter %}
-
-returns ``"<b>some text</b>"``.
-
-
-Defining Variables
-==================
-
-You can also define variables in the namespace using the ``{% set %}`` tag:
-
-.. sourcecode:: jinja
-
- {% set foo = 'foobar' %}
- {{ foo }}
-
-This should ouput ``foobar``.
-
-For information regarding the visibility of variables have a look at the
-`Scopes and Variable Behavior`_ section.
-
-
-Reserved Keywords
-=================
-
-Jinja has some keywords you cannot use a variable names. This limitation
-exists to make templates look coherent. Syntax highlighters won't mess things
-up and you won't have the situation that some names work depending on the
-context.
-
-The following keywords exist and cannot be used as identifiers:
-
- `and`, `block`, `cycle`, `elif`, `else`, `endblock`, `endfilter`,
- `endfor`, `endif`, `endmacro`, `endraw`, `endtrans`, `extends`, `filter`,
- `for`, `if`, `in`, `include`, `is`, `macro`, `not`, `or`, `pluralize`,
- `print`, `raw`, `recursive`, `set`, `trans`, `call`, `endcall`
-
-If you want to use such a name you have to prefix or suffix it or use
-alternative names:
-
-.. sourcecode:: jinja
-
- {% for macro_ in macros %}
- {{ macro_('foo') }}
- {% endfor %}
-
-
-.. _slicing chapter: http://diveintopython.org/native_data_types/lists.html#odbchelper.list.slice
-.. _Scopes and Variable Behavior: scopes.txt
-.. _builtins: builtins.txt
+++ /dev/null
-====================
-Developer Quickstart
-====================
-
-This part of the documentation shows you how to embed Jinja into your
-application.
-
-Starting Up
-===========
-
-Here the quickest way to create a template from a string and render it:
-
-.. sourcecode:: python
-
- from jinja import Environment
- env = Environment()
- tmpl = env.from_string('Hello {{ name }}!')
- print tmpl.render(name='John Doe')
-
-This example should output the following string after execution::
-
- Hello John Doe!
-
-If you receive an error, check if you have a typo in your code. If not, have
-a look at the `installation`_ page for troubleshooting.
-
-Basically the important method on a template is the `render` method. It
-takes either a dict or keyword arguments. All keyword arguments appear
-in the template as variables.
-
-So these two snippets do the same:
-
-.. sourcecode:: python
-
- tmpl.render(
- knights='we say nih',
- spam='and eggs'
- )
-
-.. sourcecode:: python
-
- tmpl.render({
- 'knights': 'we say nih',
- 'spam': 'and eggs'
- })
-
-The Environment
-===============
-
-[[environment_doc]]
-
-The environment provides the following useful functions and properties in
-addition to the initialization values:
-
-=========================== ==================================================
-``parse(source, filename)`` Parse the sourcecode and return the abstract
- syntax tree. This tree of nodes is used by the
- `translators`_ to convert the template into
- executable source- or bytecode.
-``lex(source, filename)`` Tokenize the given sourcecode and return a
- generator of tuples in the form
- ``(lineno, token, value)``. The filename is just
- used in the exceptions raised.
- **New in Jinja 1.1**
-``from_string(source)`` Load and parse a template source and translate it
- into eval-able Python code. This code is wrapped
- within a `Template` class that allows you to
- render it.
-``get_template(name)`` Load a template from a loader. If the template
- does not exist, you will get a `TemplateNotFound`
- exception.
-=========================== ==================================================
-
-There are also some internal functions on the environment used by the template
-evaluation code to keep it sandboxed.
-
-Undefined Values
-================
-
-If a template designer tries to access a not defined value the return value
-will be the `undefined_singleton` specified in the environment. The default
-one is the `SilentUndefined` which fails in no case. Additionally there is
-a special undefined type called the `ComplainingUndefined` which is located
-in the `jinja.datastructure` module. It will raise exceptions when compared
-with other types, or when rendered.
-
-Theoretically you can provide your own singleton by subclassing
-`AbstractUndefindedType` and creating an instance of it using `make_undefined`
-(both located in `jinja.datastructure`) but those two types should cover
-the basic use cases. The `Undefined` object in that module exists for
-backwards compatibility and is an alias for `SilentUndefined`.
-
-To create your own undefined singleton do something like this:
-
-.. sourcecode:: jinja
-
- from jinja.datastructure import AbstractUndefinedType, make_undefined
-
- class MyUndefinedType(AbstractUndefindedType):
- __slots__ = ()
-
- def __iter__(self):
- return iter(int, 0)
-
- def __reduce__(self):
- return 'MyUndefined'
-
- MyUndefined = make_undefined(MyUndefinedType)
-
-The only thing you have to do is to override `__reduce__` so that it returns
-the name of the singleton instance and create the instance using
-`make_undefined`. Everything else is up to you. Note that currently attributes
-on undefined objects are available in the Jinja layer too which however
-will change in one of the next Jinja versions. So if you put a `foo` attribute
-on your undefined singleton you will be able to do ``{{ undefined.foo }}``
-by now but certainly not in the future.
-
-This limitation currently exists because undefined is treated as normal object
-and thus affected by normal getattr calls.
-
-
-Automatic Escaping
-==================
-
-Jinja provides a way for automatic escaping, but we do not recommend using it.
-Because Jinja was designed as multi purpose template engine there are some
-issues with automatic escaping. For example filters don't deal with markup
-data. Also you can easily bypass the automatic escaping so it's not something
-you can expect to "just work". Also there is a huge overhead when escaping
-everything.
-
-The best idea is to think about which data already contains html, which will
-probably contain (eg: every user input, etc) etc. And live with self escaping.
-
-That's usually a much better idea.
-
-
-Loading Templates From Files
-============================
-
-Loading templates from a string is always a bad idea. It doesn't allow template
-inheritance and is also slow since it parses and compiles the template again
-and again whereas loaders can cache the template code.
-
-All you have to do is to define a loader and use the `get_template` function.
-
-.. sourcecode:: python
-
- from jinja import Environment, FileSystemLoader
- env = Environment(loader=FileSystemLoader('templates'))
- tmpl = env.get_template('index.html')
- print tmpl.render(name='John Doe')
-
-This tells jinja to look for templates in the ``templates`` folder. It's a
-better idea to use an absolute path here though. For a list of supported
-loaders or how to write your own, head over to the `loader`_ documentation.
-
-Adding Filters
-==============
-
-If you want to add additional filters to the environment, the best way is to
-modify the ``filters`` attribute and not to pass a dict to the environment.
-If you pass it a dict it will not include the default filters!
-
-.. sourcecode:: python
-
- from mylib import my_cool_filter
- env.filters['mycoolfilter'] = my_cool_filter
-
-Writing filter functions is explained in the `filter development`_ section.
-
-Adding Tests
-============
-
-Adding additional tests works analogous to filters:
-
-.. sourcecode:: python
-
- from mylib import my_cool_test
- env.tests['mycooltest'] = my_cool_test
-
-Writing tests is explained in the `test development`_ section.
-
-
-.. _installation: installation.txt
-.. _context documentation: contextenv.txt
-.. _loader: loaders.txt
-.. _translators: translators.txt
-.. _filter development: filters.txt
-.. _test development: tests.txt
+++ /dev/null
-=======================
-Recipies For Developers
-=======================
-
-Here some recipies for application developers.
-
-
-Automagic Template Variables
-============================
-
-Python allows some magic stack manipulation which can be used to
-pass variables to templates automatically. It's not a recommended
-way to pass variables to templates but it can be useful for some
-small generation scripts etc.
-
-Just subclass the environment and add an `autorender` function like
-this:
-
-.. sourcecode:: python
-
- import sys
- from jinja import Environment
-
- class AutoEnvironment(Environment):
-
- def autorender(self, template):
- tmpl = self.get_template(template)
- return tmpl.render(sys._getframe(1).f_locals)
-
-You can use it now like this:
-
-.. sourcecode:: python
-
- def foo():
- seq = range(10)
- foo = "blub"
- return env.autorender('foo.html')
-
-In the template you can now access the local variables `seq` and `foo`.
-
-
-Using Django Filters with Jinja
-===============================
-
-If you use Jinja in django and want to use some of the filters that
-are part of the django core you can use this snippet:
-
-.. sourcecode:: python
-
- def convert_django_filter(f):
- def filter_factory(*args):
- def wrapped(env, ctx, value):
- return f(value, *args)
- return wrapped
- return filter_factory
-
-You can now convert django filters for jinja using `convert_filter`. *Note*:
-Django only supports one filter argument. Because of this limitation you
-shouldn't pass it more arguments than it accepts. Because django uses some
-introspection to find out if a filter accepts an argument weird things can
-happen if you call it with an incompatible argument count.
-
-You can now register django filters for a jinja environment:
-
-.. sourcecode:: python
-
- from django.template.defaultfilters import date
- env.filters['date'] = convert_django_filter(date)
-
-And use it:
-
-.. sourcecode:: jinja
-
- {{ entry.pub_date|date }}
-
-Also keep in mind that Jinja knows about keywords, thus you cannot have a filter
-that is called `pluralize` for example.
-
-Such a conversion function is also part of the djangosupport module which was
-introduced in Jinja 1.2. It's explained on the `Framework Integration`_ page.
-
-
-Using Jinja in Django
-=====================
-
-.. admonition:: Note
-
- This section is more or less obsolete as of Jinja 1.2 which provides a
- djangosupport module, covered on the `Framework Integration`_ page.
-
-This snippet was contributed by Bryan McLemore. It provides a `render_to_response`
-function similar to the one shipped with django just that it uses Jinja for
-rendering. It applies the context processors on the context and consumes a
-`RequestContext`:
-
-.. sourcecode:: python
-
- from django.template.context import get_standard_processors
- from django.http import HttpResponse
- from jinja import Environment, FileSystemLoader, ChoiceLoader
- from django.conf import settings
-
- loaders = []
- for location in settings.TEMPLATE_DIRS:
- loaders.append(FileSystemLoader(location))
- env = Environment(loader=ChoiceLoader(loaders))
-
- def render_to_response(template, context, request=None):
- template = env.get_template(template)
- if request:
- for processor in get_standard_processors():
- context.update(processor(request))
- return HttpResponse(template.render(context))
-
-
-If you want to plug Jinja into the Django i18n system you can use this
-environment class:
-
-.. sourcecode:: python
-
- from jinja import Environment
- from django.utils.translation import gettext, ngettext
-
- class DjangoTranslator(object):
-
- def __init__(self):
- self.gettext = gettext
- self.ngettext = ngettext
-
- class DjangoEnvironment(Environment):
-
- def get_translator(self, context):
- return DjangoTranslator()
-
-Because Django uses gettext internally we can create just assign the
-ngettext and gettext functions directly to the translator class.
-
-
-.. _Framework Integration: frameworks.txt
+++ /dev/null
-=======================
-Whitespace and Escaping
-=======================
-
-This section of the documentation explains how to remove unused whitespace
-from the templates and embed raw Jinja syntax.
-
-Escaping
-========
-
-Sometimes you might want to add Jinja syntax elements into the template
-without executing them. In that case you have quite a few possibilities.
-
-For small parts this might be a good way:
-
-.. sourcecode:: jinja
-
- {{ "{{ foo }} is variable syntax and {% foo %} is block syntax" }}
-
-When you have multiple elements you can use the ``raw`` block:
-
-.. sourcecode:: jinja
-
- {% raw %}
- Filtering blocks works like this in Jinja:
- {% filter escape %}
- <html>
- <code>goes here</code>
- </html>
- {% endfilter %}
- {% endraw %}
-
-
-Whitespace
-==========
-
-If the Jinja environment was created with ``trim_blocks`` set to true the
-first newline after a template tag is removed automatically (php like
-processing).
-
-Starting with `Jinja 1.1` you can also handle some whitespace rules in the
-template. If you put an minus sign (`-`) to the start or end of an block
-(for example a `for` tag), a comment or variable element you can remove
-the whitespaces after or before that block:
-
-.. sourcecode:: jinja
-
- {% for item in seq -%}
- {{ item }}
- {%- endfor %}
-
-This will yield all elements without whitespace between them because they
-are automatically removed. This of course works for other tags too:
-
-.. sourcecode:: jinja
-
- {% for user in userlist -%}
- {{ user|e -}}
- {% if not loop.last %},{% endif %}
- {%- endfor %}
-
-Note that you must not use a whitespace between the tag and the minus sign:
-
-.. sourcecode:: jinja
-
- valid:
- {%- if foo -%}...{% endif %}
-
- invalid:
-
- {% - if foo - %}...{% endif %}
+++ /dev/null
-================
-Filter Functions
-================
-
-Filters are a powerful feature of Jinja taken from django which probably took
-it from UNIX. The idea is that you "pipe" a value through some filters to
-do something with it. For example convert it to upper case, escape it or
-replace a substring.
-
-Jinja comes with some builtin filters explained in the `designer documentation`_.
-
-Writing Filters
-===============
-
-A filter basically is a factory function, a function that returns another
-function. We do this because filters can get an unlimited amount of positional
-arguments and aditionally should gain access to the environment, context and
-piped value. A simple filter looks like this:
-
-.. sourcecode:: python
-
- def do_join(d=u''):
- def wrapped(env, context, value):
- tmp = []
- for item in value:
- tmp.append(env.to_unicode(item))
- return d.join(tmp)
- return wrapped
-
-Now you have to register that filter on an environment:
-
-.. sourcecode:: python
-
- env.filters['join'] = do_join
-
-In fact this filter is already bundled so you won't see any effect. But it
-should explain how such a filter looks like. The template designer can just
-trigger the outer code (i.e. call `join` with or without arguments). The
-returned function is then processed by the jinja template engine once all
-filters are created.
-
-If you want to create filters that just operate on a string (in fact unicode
-objects) you can use the `stringfilter` decorator:
-
-.. sourcecode:: python
-
- from jinja.filters import stringfilter
-
- @stringfilter
- def do_strip(value):
- return value.strip()
-
-The wrapped function is created internally by the decorator, any positional
-arguments are forwarded to the filter function. The first argument is always
-the value already converted into a string.
-
-If you're using Jinja with django and want to use the django filters in Jinja
-have a look at the `developer recipies`_ page.
-
-*new in Jinja 1.1* additionally to the `stringfilter` decorator there is now
-a similar decorator that works exactly the same but does not convert values
-to unicode:
-
-.. sourcecode:: python
-
- from jinja.filters import simplefilter
-
- @simplefilter
- def do_add(value, to_add):
- return value + to_add
-
-.. _designer documentation: builtins.txt
-.. _developer recipies: devrecipies.txt
+++ /dev/null
-=====================
-Framework Integration
-=====================
-
-Starting with Jinja 1.1 it's possible to embed Jinja into some of the existing
-frameworks a lot easier. When speaking of frameworks we only refer to `Pylons`_
-which has a working implementation of the TurboGears template specification.
-
-Since the whole situation is problematic because of various reasons (kid
-specific, uses dotted names for template loading, package name prefix etc.)
-we worked around some of the problems by using pylons specific workarounds.
-
-Jinja also ships an implementation for a hypothetical template abstraction layer
-called `General Template Interface`_ which isn't implemented by any existing
-framework so far. This specification however tries to solve the problems that
-exist in Buffet.
-
-
-Buffet
-======
-
-The buffet specification proposes that templates are named in dotted names. That
-means `foo.bar` and not `foo/bar.html`. The dotted notation has the disadvantage
-that you cannot specify the filename extension. In recent pylons versions it's
-however possible to load templates with their native path too if you prefix the
-template name with a foreslash (`/foo/bar.html`). If you don't specify the
-extension it will assume `.html` for the dotted notation.
-
-Here the list of configuration values:
-
-======================= ======================================================
-``jinja.extension`` The template extension when templates are loaded using
- the dotted notation. Defaults to ``html``.
-``jinja.environment`` If this is provided it must be the only configuration
- value and it's used as jinja environment. In that
- case all other configuration parameters except of
- ``jinja.extension`` are ignored.
-``jinja.searchpath`` If provided a new file system loader with this
- search path is instanciated.
-``jinja.package`` Name of the python package containing the
- templates. If this and ``package_path`` is
- defined a `PackageLoader` is used.
-``jinja.package_path`` Path to the templates inside of a package.
-``jinja.loader_func`` Function that takes the name of the template to
- load. If it returns a string or unicode object
- it's used to load a template. If the return
- value is None it's considered missing.
-``jinja.getmtime_func`` Function used to check if templates requires
- reloading. Has to return the UNIX timestamp of
- the last template change or 0 if this template
- does not exist or requires updates at any cost.
-``jinja.use_memcache`` Set this to ``True`` to enable memory caching.
- This is usually a good idea in production mode,
- but disable it during development since it won't
- reload template changes automatically.
- This only works in persistent environments like
- FastCGI.
-``jinja.memcache_size`` Number of template instance you want to cache.
- Defaults to ``40``.
-``jinja.cache_folder`` Set this to an existing directory to enable
- caching of templates on the file system. Note
- that this only affects templates transformed
- into python code. Default is ``None`` which means
- that caching is disabled.
-``jinja.auto_reload`` Set this to `False` for a slightly better
- performance. In that case of `getmtime_func`
- not being provided this won't have an effect.
-======================= ======================================================
-
-All other options that start with `jinja.` are automatically forwarded to the
-environment constructor.
-
-In pylons for example you can use jinja as buffet plugin like this:
-
-Edit the `yourproject/config/middleware.py` and add this to `config.init_app`:
-
-.. sourcecode:: python
-
- config.add_template_engine('jinja', '', {
- 'jinja.package': 'yourapplication',
- 'jinja.package_path': 'res/templates',
- 'jinja.use_memcache': True
- })
-
-Note that it's a good idea to set the second parameter to an empty string.
-It's meant to be used as replacement for the turbogears package name but
-Jinja assumes that the name of the template does not include the package
-path.
-
-.. admonition:: Note
-
- Special note for pylons users. Jinja will be unable to request attributes
- from the special `c` object, unless you set `strict_c` to `True` in the
- `environment.py`:
-
- .. sourcecode:: python
-
- return pylons.config.Config(tmpl_options, map, paths, strict_c=True)
-
-You can then render the template in the view like this:
-
-.. sourcecode:: python
-
- class ExampleController(BaseController):
-
- def index(self):
- c.title = "Your Page"
- c.message = 'hi'
- return render_response('jinja', 'test_template')
-
- def download(self):
- c.title = "Downloads"
- c.downloads = [1, 2, 3]
- return render_response('jinja', '/downloads.html')
-
-With the settings from above rendering the `index` action will result in
-rendering the template ``res/templates/test_template.html`` where res is
-a folder in the ``yourapplication`` python package.
-
-The `downloads` action uses the pylons specific leading foreslash notation.
-
-
-General Template Interface
-==========================
-
-Because nobody implemented this specification so far it's not documented here
-but in the sourcecode of the `plugin module`_. The specification itself is
-explained on the pocoo trac on the `General Template Interface`_ wiki page.
-
-
-Django
-======
-
-Using Jinja in django is straightforward because django has a pretty low
-level response interface. Just have a look at the `developer recipies`_,
-there are some examples for django. Starting with Jinja 1.2 there is also
-a contrib module that simplifies using Jinja in an unicode enabled django.
-
-Quickstart
-----------
-
-To get started execute the following code at the bottom of your settings.py
-or in some general application file such as urls.py or a central module. The
-only thing that matters is that it's executed right *after* the settings
-were set up and *before* `django.contrib.jinja` is imported::
-
- from jinja.contrib import djangosupport
- djangosupport.configure()
-
-What this does is setting up a Jinja environment for this django instance
-with loaders for `TEMPLATE_DIRS` etc. It also converts a couple of default
-django filters such as `date` and `timesince` which are not available in
-Jinja per default. If you want to change the list you can provide others
-by passing a list with filter import names as `convert_filters` keyword
-argument.
-
-All other keyword arguments are forwarded to the environment. If you want
-to provide a loader yourself pass it a loader keyword argument.
-
-Rendering Templates
--------------------
-
-To render a template you can use the functions `render_to_string` or
-`render_to_response` from the `django.contrib.jinja` module::
-
- from django.contrib.jinja import render_to_response
- resp = render_to_response('Hello {{ username }}!', {
- 'username': req.session['username']
- }, req)
-
-`render_to_string` and `render_to_response` take at least the name of
-the template as argument, then the optional dict which will become the
-context. If you also provide a request object as third argument the
-context processors will be applied.
-
-`render_to_response` also takes a forth parameter which can be the
-content type which defaults to `DEFAULT_CONTENT_TYPE`.
-
-Converting Filters
-------------------
-
-One of the useful objects provided by `django.contrib.jinja` is the
-`register` object which can be used to register filters, tests and
-global objects. You can also convert any filter django provides in
-a Jinja filter using `convert_django_filter`::
-
- from django.contrib.jinja import register, convert_django_filter
- from django.template.defaultfilters import floatformat
-
- register.filter(convert_django_filter(floatformat), 'floatformat')
-
-Available methods on the `register` object:
-
-``object (obj[, name])``
- Register a new global as name or with the object's name.
- Returns the function object unchanged so that you can use
- it as decorator if no name is provided.
-
-``filter (func[, name])``
- Register a function as filter with the name provided or
- the object's name as filtername.
- Returns the function object unchanged so that you can use
- it as decorator if no name is provided.
-
-``test (func[, name])``
- Register a function as test with the name provided or the
- object's name as testname.
- Returns the function object unchanged so that you can use
- it as decorator if no name is provided.
-
-``context_inclusion (func, template[, name])``
- Register a function with a name provided or the func object's
- name in the global namespace that acts as subrender function.
-
- func is called with the callers context as dict and the
- arguments and keywords argument of the inclusion function.
- The function should then process the context and return a
- new context or the same context object. Afterwards the
- template is rendered with this context.
-
- Example::
-
- def add_author(context, author=None):
- if author is not None:
- author = Author.objects.get(name=author)
- context['author'] = author
- return context
-
- register.context_inclusion(add_author, 'author_details.html',
- 'render_author_details')
-
- You can use it in the template like this then::
-
- {{ render_author_details('John Doe') }}
-
-``clean_inclusion (func, template[, name[, run_processors]])``
- Works like `context_inclusion` but doesn't use the calles
- context but an empty context. If `run_processors` is `True`
- it will lookup the context for a `request` object and pass
- it to the render function to apply context processors.
-
-
-
-.. _Pylons: http://www.pylonshq.com/
-.. _General Template Interface: http://trac.pocoo.org/wiki/GeneralTemplateInterface
-.. _plugin module: http://trac.pocoo.org/browser/jinja/trunk/jinja/plugin.py
-.. _developer recipies: devrecipies.txt
+++ /dev/null
-===============================
-Differences To Django Templates
-===============================
-
-If you have previously worked with Django templates, you should find Jinja very
-familiar. In fact, most of the syntax elements look and work the same.
-
-However, Jinja provides some more syntax elements covered in the documentation
-and some work a bit different.
-
-Method Calls
-============
-
-In Django method calls work implicitly. With Jinja you have to specify that you
-want to call an object. Thus this Django code:
-
-.. sourcecode:: django
-
- {% for page in user.get_created_pages %}
- ...
- {% endfor %}
-
-will look like this in Jinja:
-
-.. sourcecode:: jinja
-
- {% for page in user.get_created_pages() %}
- ...
- {% endfor %}
-
-This allows you to pass variables to the function which is also used for
-macros and loop recursion, both features that don't exist in Django.
-
-Conditions
-==========
-
-In Django you can use the following constructs to check for equality:
-
-.. sourcecode:: django
-
- {% ifequals foo "bar" %}
- ...
- {% else %}
- ...
- {% endifequals %}
-
-In Jinja you can use the normal ``if`` statement in combination with
-operators:
-
-.. sourcecode:: jinja
-
- {% if foo == 'bar' %}
- ...
- {% else %}
- ...
- {% endif %}
-
-You can also have multiple ``elif`` branches in your template:
-
-.. sourcecode:: jinja
-
- {% if something %}
- ...
- {% elif otherthing %}
- ...
- {% elif foothing %}
- ...
- {% else %}
- ...
- {% endif %}
-
-Filter Arguments
-================
-
-Jinja provides more than one argument for filters. Also the syntax for argument
-passing is different. A template that looks like this in Django:
-
-.. sourcecode:: django
-
- {{ items|join:", " }}
-
-looks like this in jinja:
-
-.. sourcecode:: jinja
-
- {{ items|join(', ') }}
-
-In fact it's a bit more verbose but it allows different types of arguments - including
-variables - and more than one of them.
-
-Tests
-=====
-
-In addition to filters there also are tests you can perform using the `is` operator.
-Here are some examples:
-
-.. sourcecode:: jinja
-
- {% if user.user_id is odd %}
- {{ user.username|e }} is odd
- {% else %}
- hmm. {{ user.username|e }} looks pretty normal
- {% endif %}
-
-For a list of supported tests head over to the `syntax reference`_.
-
-
-.. _syntax reference: designerdoc.txt
+++ /dev/null
-====================
-Internationalization
-====================
-
-Jinja includes support for internationalized templates. Because usually the
-application includes i18n/l10n code too there is no script to collect
-translatable strings and no default translation interface. A simple
-implementation wouldn't fit into every application so there are a few things
-you have to do.
-
-
-Writing A Translator
-====================
-
-The most important thing is writing a translator and subclassing the
-Environment so that Jinja knows about the translator. Then you have to
-think of how to resolve the current language. You probably use Jinja in a
-multithreaded environment where each thread (request) might want to have
-a different language. The best way is putting the current language into
-the context, this can work automatically if you create a helper function
-for template rendering. But that's up to you.
-
-However. For many web applications this might be a way:
-
-.. sourcecode:: python
-
- from jinja import Environment
- from myapplication import get_translator
-
- class ApplicationTranslator(object):
-
- def __init__(self, language):
- self.language = language
- self.translator = get_translator(language)
-
- def gettext(self, string):
- return self.translator.ugettext(string)
-
- def ngettext(self, singular, plural, n):
- return self.translator.ungettext(singuarl, plural, n)
-
-
- class ApplicationEnvironment(Environment):
-
- def get_translator(self, context):
- return ApplicationTranslator(context['LANGUAGE'])
-
-
- env = ApplicationEnvironment()
- tmpl = env.get_template('index.html')
- tmpl.render(LANGUAGE='de_DE')
-
-This example assumes that you use gettext and have a gettext `Translations`
-object which is returned by the `get_translator` function. But you don't
-have to use gettext. The only thing Jinja requires is an object with to
-functions/methods on it that return and accept unicode strings:
-``gettext(string)`` that takes a string, translates and returns it, a
-``ngettext(singular, plural, count)`` function that returns the correct plural
-form for `count` items. Because some languages have no or multiple plural
-forms this is necessary.
-
-
-Translator Factory
-==================
-
-With Jinja 1.2 onwards it's possible to use a translator factory
-instead of an enviornment subclass to create a translator for a context.
-A translator factory is passed a context and has to return a translator.
-Because of the way classes work you can also assign a translator class
-that takes a context object as only argument as factory.
-
-Example:
-
-.. sourcecode:: python
-
- from jinja import Environment
- from myapplication import get_translator
-
- def translator_factory(context):
- return get_translator(context['LANGUAGE'])
-
- env = ApplicationEnvironment(translator_factory=translator_factory)
- tmpl = env.get_template('index.html')
- tmpl.render(LANGUAGE='de_DE')
-
-This example assumes that the translator returned by `get_translator`
-already has a gettext and ngettext function that returns unicode strings.
-
-
-Collecting Translations
-=======================
-
-The next step is to collect the translations. Every Jinja environment
-provides a function called `get_translations` which collects all
-translatable strings from an template.
-
-Example:
-
-.. sourcecode:: pycon
-
- >>> env.get_translations('index.html')
- [(1, u'foo', None), (2, u'Foo', None), (3, u'%(count)s Foo', u'%(count)s Foos')]
-
-The first item in the tuple is the linenumer, the second one is the
-singular form and the third is the plural form if given.
-
-Because Jinja is not bound to gettext you can now use these strings to
-create translation files for any translation system.
-
-*New in Jinja 1.1* You can now extract translations from strings according
-to the current envrionment settings too by using the environment method
-`get_translations_for_string` which takes a string containing a template
-as only argument. The return value is the same as for `get_translations`.
+++ /dev/null
-======================
-Documentation Overview
-======================
-
-Welcome in the Jinja documentation.
-
-- `Installing Jinja <installation.txt>`_
-
-- **Application Developer Documentation**:
-
- - `Quickstart <devintro.txt>`_ - getting started with Jinja
-
- - `Template Loaders <loaders.txt>`_ - documentation for the different
- loader types and how to write custom ones.
-
- - `Filter Functions <filters.txt>`_ - information about how to write
- custom filter functions.
-
- - `Test Functions <tests.txt>`_ - information about how to write
- custom test functions.
-
- - `Global Objects <objects.txt>`_ - information about the special global
- namespace in Jinja templates.
-
- - `Streaming Interface <streaming.txt>`_ - using Jinja for big templates
- by streaming the output.
-
- - `Internationalization <i18n.txt>`_ - how to internationalize applications
- using Jinja templates.
-
- - `Alternative Syntax <altsyntax.txt>`_ - changing the default Jinja
- block / variable / comment delimiters.
-
- - `API Documentation <api.txt>`_ - API documentation for public Jinja
- objects like `Environment`.
-
- - `Translators <translators.txt>`_ - explanation about the Jinja template
- translation interface.
-
- - `Framework Integration <frameworks.txt>`_ - integrating Jinja into
- python frameworks.
-
- - `Debugging Support <debugging.txt>`_ - debugging Jinja templates.
-
- - `Developer Recipies <devrecipies.txt>`_ - tips and tricks for application
- developers.
-
-- **Template Designer Documentation**:
-
- - `Syntax Reference <designerdoc.txt>`_ - quick overview over the Jinja
- syntax elements.
-
- - `Template Inheritance <inheritance.txt>`_ - template inheritance howto.
-
- - `Filters, Tests and Helper Functions <builtins.txt>`_ - list of filters
- and test/helper functions.
-
- - `Whitespace and Escaping <escaping.txt>`_ - how to escape markup and
- control whitespace.
-
- - `Scopes and Variable Behavior <scopes.txt>`_ - behavior of undefined
- variables and scoping rules.
-
- - `Template Internationalization <templatei18n.txt>`_ - how to internationalize
- Jinja templates.
-
- - `Differences To Django <fromdjango.txt>`_ - coming from django? Then this
- document is for you.
-
- - `Designer Recipies <recipies.txt>`_ - various tips and tricks for designers.
-
-- `Changelog <changelog.txt>`_
-
-There is also support via IRC on the ``#pocoo`` channel on `irc.freenode.net`.
+++ /dev/null
-====================
-Template Inheritance
-====================
-
-The most powerful part of Jinja is template inheritance. Template inheritance
-allows you to build a base "skeleton" template that contains all the common
-elements of your site and defines **blocks** that child templates can override.
-
-Sounds complicated but is very basic. It's easiest to understand it by starting
-with an example.
-
-
-Base Template
-=============
-
-This template, which we'll call ``base.html``, defines a simple HTML skeleton
-document that you might use for a simple two-column page. It's the job of
-"child" templates to fill the empty blocks with content:
-
-.. sourcecode:: html+jinja
-
- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
- <html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <link rel="stylesheet" href="style.css" />
- <title>{% block title %}{% endblock %} - My Webpage</title>
- {% block html_head %}{% endblock %}
- </head>
- <body>
- <div id="content">
- {% block content %}{% endblock %}
- </div>
-
- <div id="footer">
- {% block footer %}
- © Copyright 2006 by <a href="http://mydomain.tld">myself</a>.
- {% endblock %}
- </div>
- </body>
-
-In this example, the ``{% block %}`` tags define four blocks that child templates
-can fill in. All the `block` tag does is to tell the template engine that a
-child template may override those portions of the template.
-
-
-Child Template
-==============
-
-A child template might look like this:
-
-.. sourcecode:: html+jinja
-
- {% extends "base.html" %}
- {% block title %}Index{% endblock %}
-
- {% block html_head %}
- <style type="text/css">
- .important {
- color: #336699;
- }
- </style>
- {% endblock %}
-
- {% block content %}
- <h1>Index</h1>
- <p class="important">
- Welcome on my awsome homepage.
- </p>
- {% endblock %}
-
-The ``{% extends %}`` tag is the key here. It tells the template engine that
-this template "extends" another template. When the template system evaluates
-this template, first it locates the parent. It must be always the first tag
-in a template but whitespace or a comment is allowed before. This was not
-enforced with Jinja 1.0 and 1.1, it does however raise a syntax error with
-1.2 or later.
-
-The filename of the template depends on the template loader. For example the
-``FileSystemLoader`` allows you to access other templates by giving the
-filename. You can access templates in subdirectories with an slash:
-
-.. sourcecode:: jinja
-
- {% extends "layout/default.html" %}
-
-But this behavior can depend on the application using Jinja.
-
-Note that since the child template didn't define the ``footer`` block, the
-value from the parent template is used instead.
-
-.. admonition:: Note
-
- You can't define multiple ``{% block %}`` tags with the same name in the
- same template. This limitation exists because a block tag works in "both"
- directions. That is, a block tag doesn't just provide a hole to fill - it
- also defines the content that fills the hole in the *parent*. If there were
- two similarly-named ``{% block %}`` tags in a template, that template's
- parent wouldn't know which one of the blocks' content to use.
-
-
-How Inheritance Works Internally
-================================
-
-Inheritance in Jinja is straightforward. If a template contains an
-``{% extends %}`` tag it's considered being a child template, otherwise it's
-a layout template. In a layout template you can place blocks basically
-everywhere. In a child template blocks can only be located either at the
-top level or inside another block.
-
-Data outside of a block in a child template is executed before the layout
-template is rendered, thus you can use it to propagate data to the whole
-inheritance chain. Having a block in an invalid position you will receive
-an syntax error. Here some examples:
-
-**impossible**:
-
- .. sourcecode:: jinja
-
- {% extends 'master.html' %}
- {% if some_condition %}
- {% block body %}
- ...
- {% endblock %}
- {% endif %}
-
- This can't work because template inheritance works at translation /
- compilation time not at template execution.
-
-**possible**:
-
- .. sourcecode:: jinja
-
- {% extends 'master.html' %}
- {% block body %}
- {% if some_condition %}
- {% block myblock %}
- ...
- {% endblock %}
- {% endif %}
- {% endblock %}
-
- This can work although it probably makes no sense in this specific case.
- However the condition is handled at runtime because it's in a valid block
- and defines a new block subtemplates can override.
-
-
-.. admonition:: Note
-
- Unlike Python Jinja does not support multiple inheritance. So you can
- only have one extends tag with only one constant string argument.
-
-
-Super Blocks
-============
-
-Starting with `Jinja 1.1` it's possible to render the contents of the parent
-block. By calling it you get the results of the parent block back. If you want
-to get the data of the parent you can give it an offset:
-
-.. sourcecode:: jinja
-
- {{ super() }}
- return the parent data
-
- {{ super(1) }}
- the same as above
-
- {{ super(2) }}
- return the data of the second parent block
-
-
-Block Shortcuts
-===============
-
-With Jinja 1.1 onwards it's possible to have a shortcut syntax for blocks
-with few content. The following constructs do the same:
-
-.. sourcecode:: jinja
-
- {% block title %}{{ page_title }}{% endblock %}
-
- {% block title page_title %}
-
-Note that as soon as you specify a second argument it's threated as
-short block and Jinja won't look for an closing tag.
+++ /dev/null
-============
-Installation
-============
-
-Jinja requires at least Python 2.3 to work correctly.
-
-
-Installing a released version
-=============================
-
-As a Python egg (via easy_install)
-----------------------------------
-
-You can install the most recent Jinja version using `easy_install`_::
-
- sudo easy_install Jinja
-
-This will install a Jinja egg in your Python installation's site-packages
-directory.
-
-From the tarball release
--------------------------
-
-1. Download the most recent tarball from the `download page`_
-2. Unpack the tarball
-3. ``sudo python setup.py install``
-
-Note that the last command will automatically download and install
-`setuptools`_ if you don't already have it installed. This requires a working
-internet connection.
-
-This will install Jinja into your Python installation's site-packages directory.
-
-
-Installing the development version
-==================================
-
-If you want to play around with the code
-----------------------------------------
-
-1. Install `mercurial`_
-2. ``svn co http://dev.pocoo.org/hg/jinja-main jinja``
-3. ``cd jinja``
-4. ``ln -s jinja /usr/lib/python2.X/site-packages``
-
-As an alternative to steps 4 you can also do ``python setup.py develop``
-which will install the package via setuptools in development mode. This also
-has the advantage that the c extensions are compiled.
-
-If you just want the latest features and use them
--------------------------------------------------
-
-::
-
- sudo easy_install Jinja==dev
-
-This will install a Jinja egg containing the latest Subversion trunk code
-in your Python installation's site-packages directory. Every time the command
-is run, the sources are updated from Subversion.
-
-
-Windows Installation Information
-================================
-
-On windows computers without Visual Studio 2003 Jinja is unable to compile the
-C extensions. This is usually not a problem because there is a fallback for
-native Python implementations of those C libraries. However under certain
-conditions the installation may fail with an error message. In that case try
-to disable the extensions by passing the following parameters to setup.py::
-
- python setup.py install --without-speedups --without-extended-debugger
-
-
-Documentation
-=============
-
-The egg builds include a documentation which is available in the ``docs`` folder
-of the egg. If you're running linux you will find the documentation here::
-
- file:///usr/lib/python2.X/site-packages/Jinja-Y.Z-py2.X.egg/docs/index.html
-
-where ``X``, ``Y`` and ``Z`` must be replaced by the python / jinja version
-number.
-
-
-.. _download page: http://jinja.pocoo.org/download.html
-.. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools
-.. _easy_install: http://peak.telecommunity.com/DevCenter/EasyInstall
-.. _mercurial: http://www.selenic.com/mercurial/
+++ /dev/null
-================
-Template Loaders
-================
-
-This part of the documentation explains how to use and write a template loader.
-
-Builtin Loaders
-===============
-
-This list contains the builtin loaders you can use without further
-modification:
-
-[[list_of_loaders]]
-
-Loader Baseclasses
-==================
-
-With Jinja 1.1 onwards all the loaders have (except of the uncached)
-baseclasses. You can use them to mix your own caching layer in. This technique
-is described below. The `BaseLoader` itself is also a loader baseclass but
-because it's the baseclass of all loaders it's covered in the "Developing
-Loaders" section.
-
-[[list_of_baseloaders]]
-
-Developing Loaders
-==================
-
-Template loaders are just normal Python classes that have to provide some
-functions used to load and translate templates. Because some of the tasks
-a loader has to do are redundant there are some classes that make loader
-development easier.
-
-Here the implementation of a simple loader based on the `BaseLoader` from
-`jinja.loaders`:
-
-.. sourcecode:: python
-
- import codecs
- from os.path import join
- from jinja.loaders import BaseLoader
- from jinja.exceptions import TemplateNotFound
-
- class SimpleLoader(BaseLoader):
-
- def __init__(self, path):
- self.path = path
-
- def get_source(self, environment, name, parent):
- filename = join(self.path, name)
- if not path.exists(filename):
- raise TemplateNotFound(name)
- f = codecs.open(filename, 'r', environment.template_charset)
- try:
- return f.read()
- finally:
- f.close()
-
-The functions `load` and `parse` which are a requirement for a loader are
-added automatically by the `BaseLoader`. Instead of the normal `BaseLoader`
-you can use one of the other base loaders that already come with a proper
-`get_source` method for further modification. Those loaders however are
-new in Jinja 1.1.
-
-CachedLoaderMixin
------------------
-
-Additionally to the `BaseLoader` there is a mixin class called
-`CachedLoaderMixin` that implements memory and disk caching of templates.
-Note that you have to give it a higher priority in the MRO than the
-`BaseLoader` which means that's the first base class when inheriting from it:
-
-.. sourcecode:: python
-
- import codecs
- from os.path import join, getmtime, exists
- from jinja.loaders import BaseLoaderCachedLoaderMixin
- from jinja.exceptions import TemplateNotFound
-
- class CachedLoader(CachedLoaderMixin, BaseLoader):
-
- def __init__(self, path):
- self.path = path
- CachedLoaderMixin.__init__(self,
- True, # use memory caching
- 40, # for up to 40 templates
- '/tmp', # additionally save the compiled templates in /tmp
- True, # and reload cached templates automatically if changed
- 'foo' # optional salt used to keep templates with the same
- # name in the same cache folder, but from different
- # loaders. New in Jinja 1.1 and can be omitted.
- )
-
- def get_source(self, environment, name, parent):
- filename = join(self.path, name)
- if not path.exists(filename):
- raise TemplateNotFound(name)
- f = codecs.open(filename, 'r', environment.template_charset)
- try:
- return f.read()
- finally:
- f.close()
-
- def check_source_changed(self, environment, name):
- fn = join(self.path, name)
- if exists(fn):
- return getmtime(fn)
- return -1
-
-You don't have to provide the `check_source_changed` method. If it doesn't
-exist the option `auto_reload` won't have an effect. Also note that the
-`check_source_changed` method must not raise an exception if the template
-does not exist but return ``-1``. The return value ``-1`` is considered
-"always reload" whereas ``0`` means "do not reload". The default return
-value for not existing templates should be ``-1``.
-
-For the default base classes that come with Jinja 1.1 onwards there exist
-also concrete implementations that support caching. The implementation
-just mixes in the `CachedLoaderMixin`.
-
-MemcachedLoaderMixin
---------------------
-
-*New in Jinja 1.1*
-
-The `MemcachedLoaderMixin` class adds support for `memcached`_ caching.
-There is only one builtin loader that mixes it in: The
-`MemcachedFileSystemLoader`. If you need other loaders with this mixin
-you can easily subclass one of the existing base loaders. Here an example
-for the `FunctionLoader`:
-
-.. sourcecode:: python
-
- from jinja.loaders import FunctionLoader, MemcachedLoaderMixin
-
- class MemcachedFunctionLoader(MemcachedLoaderMixin, FunctionLoader):
-
- def __init__(self, loader_func):
- BaseFunctionLoader.__init__(self, loader_func)
- MemcachedLoaderMixin.__init__(self,
- True, # use memcached
- 60 * 60 * 24 * 7, # 7 days expiration
- ['127.0.0.1:11211'], # the memcached hosts
- 'template/' # string prefix for the cache keys
- )
-
-This mixin requires the `python-memcached`_ library.
-
-.. _memcached: http://www.danga.com/memcached/
-.. _python-memcached: http://www.tummy.com/Community/software/python-memcached/
-
-
-How Mixin Classes Work
-======================
-
-The idea of the cached loader mixins is that you override the `load`
-method of the other base class so that it's only called to get the data
-from the loader and put it into a cache and then bypass the original `load`.
-
-This works because mixin classes, as well as the loaders are so called "new
-style classes" with a MRO (method resolution order). So it's possible to
-access the parent without actually knowing the name of it.
-
-Here as small mixin class that stores everything after loading in a
-dict:
-
-.. sourcecode:: python
-
- class SimpleCacheMixin(object):
-
- def __init__(self):
- self.__cache = {}
-
- def load(self, environment, name, translator):
- if name in self.__cache:
- return self.__cache[name]
- tmpl = super(SimpleCacheMixin, self).load(environment, name,
- translator)
- self.__cache[name] = tmpl
- return tmpl
-
-You can then mix the class in like any other mixin class. Note that
-all non public attributes **must** be prefixed with two underscores to
-enable the name mangling. Otherwise the mixin class could break the
-internal structure of the loader.
-
-The ``super(SimpleCacheMixin, self)`` call returns an object that looks
-up all the attributes you request in all the parent classes. The
-`SimpleCacheMixin` just has the `object` parent which makes it a new
-style class, but as soon as a loader is mixed in it will call the
-`load` method of the loader that is the other parent of the resulting
-class. Here a full example.
-
-Combining Everything
-====================
-
-Here a full example with a custom cache mixin and a custom base loader:
-
-.. sourcecode:: python
-
- import codecs
- from os.path import join
- from jinja.loaders import BaseLoader
- from jinja.exceptions import TemplateNotFound
-
- class SimpleBaseLoader(BaseLoader):
-
- def __init__(self, path):
- self.path = path
-
- def get_source(self, environment, name, parent):
- filename = join(self.path, name)
- if not path.exists(filename):
- raise TemplateNotFound(name)
- f = codecs.open(filename, 'r', environment.template_charset)
- try:
- return f.read()
- finally:
- f.close()
-
-
- class SimpleCacheMixin(object):
-
- def __init__(self):
- self.__cache = {}
-
- def load(self, environment, name, translator):
- if name in self.__cache:
- return self.__cache[name]
- tmpl = super(SimpleCacheMixin, self).load(environment, name,
- translator)
- self.__cache[name] = tmpl
- return tmpl
-
-
- class SimpleLoader(SimpleBaseLoader, SimpleCacheMixin):
-
- def __init__(self, path):
- SimpleBaseLoader.__init__(self, path)
- SimpleCacheMixin.__init__()
-
-You can of course put all the functionallity into the `SimpleLoader` but then
-you cannot exchange parts of it without rewriting much code. In the example
-above replacing the `SimpleCacheMixin` with a `MemcachedLoaderMixin` is a
-matter of 20 seconds.
+++ /dev/null
-==============
-Global objects
-==============
-
-This section covers the behavior of global objects in the Jinja namespace and
-also the behavior of their attributes.
-
-
-Functions
-=========
-
-`Filters`_ and `Tests`_ are special kind of functions you cannot call without
-and argument. Global functions are different. Those are really just ordinary
-python functions. You can register them on the global namespace easily:
-
-.. sourcecode:: python
-
- def my_function():
- return [1, 2, 3]
-
- env.globals['my_function'] = my_function
-
-In the template you can not call it like this:
-
-.. sourcecode:: jinja
-
- {{ my_function() }}
-
-Of couse you can pass any argument to it. But what if you want to access the
-context or environment? In that case you have to decorate a function or mark
-it (both work exactly the same, but the decorator way is probably nicer if you
-have python >= 2.4):
-
-.. sourcecode:: python
-
- from cgi import escape
- from pprint import pformat
- from jinja.datastructure import contextcallable
-
- @contextcallable
- def printcontext(env, context):
- result = []
- for key, value in context.to_dict():
- result.append('<tr><th>%s</th><td>%r</td></tr>' %
- (escape(unicode(key)), escape(pformat(value))))
- return '<table>%s</table>' % u'\n'.join(result)
-
-If this function is registered in the environment namespace then and called
-from the template it should return the content of the context as simple html
-template. Of course you can modify the context too. For more informations about
-the context object have a look at the `context object`_ documentation.
-
-The new ``{% call %}`` tag that exists with Jinja 1.1 onwards can not only
-be used with Jinja macros but also with Python functions. If a template
-designers uses the ``{% call %}`` tag to call a function provided by the
-application Jinja will call this function with a keyword argument called
-`caller` which points to a `function`. If you call this function (optionally
-with keyword arguments that appear in the context) you get a string back
-that was the content of that block. This should explain this:
-
-.. sourcecode:: python
-
- def make_dialog(title, caller=None):
- body = ''
- if caller:
- body = caller(title=title)
- return '<div class="dialog"><h2>%s</h2>%s</div>' % (title, body)
-
-This can be used like this in the template now:
-
-.. sourcecode:: html+jinja
-
- {% call make_dialog('Dialog Title') %}
- This is the body of the dialog entitled "{{ title }}".
- {% endcall %}
-
-Deferred Values
-===============
-
-You can pass functions to the template that are called to provide values at
-first access. Say you want to pass the list of recently written comments to
-all templates. But not necessarily every template will render that. In that
-situation you can create a function that returns that value and wrap it in an
-`Deferred` object. The first time a template accesses the variable then the
-`Deferred` object is resolved:
-
-.. sourcecode:: python
-
- from jinja.datastructure import Deferred
- from yourapplication.models import Comments
-
- def get_recent_comments(env, context, name):
- # do what ever you want here.
- return Comments.get_recent(10)
-
- env.globals['recent_comments'] = Deferred(get_recent_comments)
-
-The function is always called with the same arguments. The first one is the
-current environment, the second the context and the third is the name of the
-variable. In this example ``recent_comments``.
-
-The value is cached until rendering/streaming finished.
-
-Unsafe Methods / Attributes
-===========================
-
-Because Jinja is sandboxed it provides several ways to prevent unsafe attribute
-access. You can mark both attributes and methods as unsafe:
-
-.. sourcecode:: python
-
- from jinja.datastructure import unsafe
-
- class MyModel(...):
-
- # just give access to a and b. Default is all
- # note that this also disallows the functions from below.
- # if you use jinja_allowed_attributes you don't have add the
- # code below since methods are treated as attributes too.
- jinja_allowed_attributes = ['a', 'b']
-
- def __init__(self, ...):
- ...
- self.a = ...
- self.b = ...
-
- # python2.4 way of marking methods
- @unsafe
- def save(self):
- """Save the model."""
-
- # python2.3 way for the same
- def delete(self):
- """Delete the model."""
- delete.jinja_unsafe_call = True
-
-
-Bypassing Automatic Filtering
-=============================
-
-With Jinja 1.1 it's possible to assign filters to any variable printed. Of
-course there are ways to bypass that in order to make sure an object does
-not get escaped etc.
-
-In order to disable automatic filtering for an object you have to make
-sure that it's either an subclass of `unicode` or implements a
-`__unicode__` method. `__str__` will work too as long as the return value
-only contains ASCII values. Additionally you have to add an attribute to
-that object named `jinja_no_finalization` and set that to `True`.
-
-
-.. _Filters: filters.txt
-.. _Tests: tests.txt
-.. _context object: contextenv.txt
+++ /dev/null
-========
-Recipies
-========
-
-Here are some typical recipes for the usage of Jinja templates.
-
-Alternating Rows
-================
-
-If you want to have different styles for each row of a table or
-list you can use the ``cycle`` tag:
-
-.. sourcecode:: html+jinja
-
- <ul>
- {% for row in sequence %}
- <li class="{% cycle 'even', 'odd' %}">{{ row|e }}</li>
- {% endfor %}
- </ul>
-
-``cycle`` can take an unlimited amount of strings. Each time this
-tag is encountered the next item from the list is rendered.
-If you pass it just one argument it's meant to be a sequence.
-
-
-Active Menu Item
-================
-
-Often you want to have a navigation bar with an active navigation
-item. This is really simple to achieve. Because ``set`` tags outside
-of ``blocks`` are global you can do something like this:
-
-**layout.html**:
-
- .. sourcecode:: html+jinja
-
- {% set navigation_bar = [
- ('/', 'index', 'Index'),
- ('/downloads/', 'downloads', 'Downloads'),
- ('/about/', 'about', 'About')
- ] %}
- ...
- <ul id="navigation">
- {% for href, id, caption in navigation_bar %}
- <li{% if id == active_page %} class="active"{% endif
- %}><a href="{{ href|e }}">{{ caption|e }}</a>/li>
- {% endfor %}
- </ul>
- ...
-
-**index.html**:
-
- .. sourcecode:: jinja
-
- {% extends "layout.html" %}
- {% set active_page = "index" %}
-
-
-Sitemap
-=======
-
-To create a sitemap you can either use the ``for`` tag or a ``macro``
-that calls itself. The datastructures should look like this:
-
-.. sourcecode:: python
-
- {'sitemap': [
- dict(
- caption='Pages',
- children=[
- dict(href='index.html', caption='Index'),
- dict(href='downloads.html', caption='Downloads'),
- dict(
- caption='Users',
- children=[
- dict(href='peter.html',
- caption='Peter'),
- dict(href='max.html',
- caption='Max'),
- dict(href='suzan.html',
- caption='Suzan')
- ]
- ),
- dict(
- caption='Files',
- children=[
- dict(
- caption='Images',
- children=[
- dict(href='vienna.html',
- caption='Vienna'),
- dict(href='roma.html',
- caption='Roma'),
- dict(href='tokyo.html',
- caption='Tokyo')
- ]
- ),
- dict(
- caption='Videos',
- children=[
- dict(href='party.html',
- caption='Party')
- ]
- )
- ]
- )
- ]
- ),
- dict(caption='Foo', href='foo.html')
- dict(caption='About', href='about.html')
- ]}
-
-Now you can create a sitemap using ``for``:
-
-.. sourcecode:: html+jinja
-
- <ul class="sitemap">
- {% for item in sitemap recursive %}
- <li><a href="{{ item.href|e }}">{{ item.caption|e }}</a>
- {% if item.children %}<ul>{{ loop(item.children) }}</ul>{% endif %}</li>
- {% endfor %}
- </ul>
-
-Or by using a ``macro`` that calls itself:
-
-.. sourcecode:: html+jinja
-
- {% macro render_sitemap items %}
- {% for item in items %}
- <li><a href="{{ item.href|e }}">{{ item.caption|e }}</a>
- {% if item.children %}<ul>{{ render_sitemap(item.children) }}</ul>{% endif %}</li>
- {% endfor %}
- {% endmacro %}
- <ul class="sitemap">{{ render_sitemap(sitemap) }}</ul>
-
-
-Using A Block Multiple Times
-============================
-
-Blocks have the small disadvantage that they work both ways which is a problem
-if you want to render a block two times on a page. Here a nice little
-workaround for this limitation:
-
-.. sourcecode:: html+jinja
-
- <html>
- <head>
- <title>{% filter capture('title') %}{%
- block title %}{% endblock %}{%
- endfilter %}</title>
- </head>
- <body>
- <div class="head">{{ title }}</div>
- </body>
- </html>
-
-Or if you use the `capture` filter in `clean` mode:
-
-.. sourcecode:: html+jinja
-
- {% filter capture('title', True)|trim %}
- {% block title %}{% endblock %}
- {% endfilter %}
- <html>
- <head>
- <title>{{ title }}</title>
- </head>
- <body>
- <div class="head">{{ title }}</div>
- </body>
- </html>
-
-
-Vim Syntax Highlighting
-=======================
-
-Because of the similar syntax to django you can use the django highlighting
-plugin for jinja too. There is however a Jinja syntax highlighting plugin
-too which supports all of the syntax elements.
-
-You can download it from the vim webpage: `jinja.vim`_
-
-
-.. _jinja.vim: http://www.vim.org/scripts/script.php?script_id=1856
+++ /dev/null
-============================
-Scopes and Variable Behavior
-============================
-
-This section of the documentation covers the Jinja behavior regarding
-variable visibility.
-
-
-Scopes
-======
-
-Jinja has multiple scopes. A scope is something like a new transparent foil on
-a stack of foils. You can only write to the outermost foil but read all of them
-since you can look through them. If you remove the top foil all data on that
-foil disappears. Some tags in Jinja add a new layer to the stack. Currently
-these are `block`, `for`, `macro` and `filter`. This means that variables and
-other elements defined inside a macro, loop or some of the other tags listed
-above will be only available in that block. Here an example:
-
-.. sourcecode:: jinja
-
- {% macro angryhello name %}
- {% set angryname = name|upper %}
- Hello {{ name }}. Hello {{ name }}!
- HELLO {{ angryname }}!!!!!!111
- {% endmacro %}
-
-The variable ``angryname`` just exists inside the macro, not outside it.
-
-Defined macros appear on the context as variables. Because of this, they are
-affected by the scoping too. A macro defined inside of a macro is just available
-in those two macros (the macro itself and the macro it's defined in).
-
-
-Template Globals
-================
-
-A special threatment exists for template code outside of visible blocks in
-child templates. This code will be executed **before** the layout template
-code. Thus it can be used to propagate values back to the layout template or
-import macros from templates for rendering.
-
-Such code can output data but it won't appear in the final rendering. So no
-additional whitespace will pollute the template.
-
-Because this code is executed before the actual layout template code it's
-possible that the layout code overrides some of those variables. Usually
-this is not a problem because of different variable names but it can be
-a problem if you plan to specify default values.
-
-In that case you have to test if the variable is not defined before setting
-it:
-
-.. sourcecode:: jinja
-
- {% if not page_title %}
- {% set page_title = 'Default Page Title' %}
- {% endif %}
-
-You can of course also use the `|default` filter.
-
-.. admonition:: Explanation
-
- This template stored as `a.html`:
-
- .. sourcecode:: html+jinja
-
- <title>{{ title|default('Untitled') }}</title>
- <body>{% block body %}{% endblock %}
-
- ...and this child template stored as `b.html`:
-
- .. sourcecode:: html+jinja
-
- {% extends 'a.html' %}
- {% include 'macros.tmpl' %}
- {% set title = 'My Page' %}
- {% block body %}{{ wrap(42) }}{% endblock %}
-
- ...and this code in `macros.tmpl`:
-
- .. sourcecode:: html+jinja
-
- {% macro wrap(text) %}
- [{{ text }}]
- {% endmacro %}
-
- ..will translate to something with the same semantics as this (just
- that the value is not stored in a variable):
-
- .. sourcecode:: html+jinja
-
- {% filter capture('captured', true) %}
- {% macro wrap(text) %}
- [{{ text }}]
- {% endmacro %}
- {% set title='My Page' %}
- {% endfilter %}
- <title>{{ title|default('Untitled') }}</title>
- <body>
- {{ wrap(42) }}
- </body>
-
-.. admonition:: Note
-
- This implementation was improved in Jinja 1.1. In Jinja 1.0 blocks that
- were not top-level were not propagated to the layout template. This made
- it impossible to use conditional expressions for inclusion in non root
- templates.
-
-
-Undefined Variables
-===================
-
-If you have already worked with python you probably know about the fact that
-undefined variables raise an exception. This is different in Jinja. There is a
-special value called `undefined` that represents values that do not exist.
-
-Depending on the configuration it will behave different.
-
-In order to check if a value is defined you can use the `defined` test:
-
-.. sourcecode:: jinja
-
- {{ myvariable is not defined }}
- will return true if the variable does not exist.
-
-`SilentUndefined`:
-
- The silent `undefined` is the default behavior. The `undefined` object works
- complete different from any variables you maybe know. If you print it
- using ``{{ variable }}`` it will not appear because it's literally empty.
- If you try to iterate over it, it will work. But no items are returned.
-
- In order to check if a value is defined you can use the `defined` test:
-
- There are also some additional rules regarding this special value. Any
- mathematical operators (``+``, ``-``, ``*``, ``/``) return the operand
- as result:
-
- .. sourcecode:: jinja
-
- {{ undefined + "foo" }}
- returns "foo"
-
- {{ undefined - 42 }}
- returns 42. Note: not -42!
-
- In any expression `undefined` evaluates to `false`. It has no length, all
- attribute calls return undefined, calling too:
-
- .. sourcecode:: jinja
-
- {{ undefined.attribute().attribute_too[42] }}
- still returns `undefined`.
-
-`ComplainingUndefined`:
-
- Starting with Jinja 1.1 it's possible to replace the default undefined
- object with different values. The other common undefined object which
- comes with Jinja is the `ComplainingUndefined` object.
-
- It raises exceptions as soon as you either render it or want to iterate
- over it or try to access attributes etc.
-
-
-Overriding Variables Of Outer Scopes
-====================================
-
-*New in Jinja 1.2*
-
-Normally you cannot override a variable from an outer scope, you can just hide
-it. There is however a way to override a variable from an outer scope using the
-`set` tag, postfixed with a bang (!):
-
-.. sourcecode:: jinja
-
- {% set last_item = none %}
- {% for item in seq %}
- {% set last_item = item! %}
- {% endfor %}
-
-After the iteration `last_item` will point to the item of the last iteration.
-
-If `last_item` was not defined in the outer scope it would be defined in the
-outermost scope.
+++ /dev/null
-===================
-Streaming Interface
-===================
-
-With Jinja 1.1 onwards it's possible to stream the template output. This is
-usually a bad idea because it's slower than `render()` but there are some
-situations where it's useful.
-
-If you for example generate a file with a couple of megabytes you may want
-to pass the stream to the WSGI interface in order to keep the amount of
-memory used low and deliver the output to the browser as fast as possible.
-
-The streaming interface is straightforward. Instead of using `render()` you
-can call `stream()` which does pretty much the same but doesn't return a
-string but a `TemplateStream`:
-
-.. sourcecode:: pycon
-
- >>> tmpl = env.from_string("<ul>{% for item in seq %}\n <li>{{ loop.index "
- ... "}} - {{ item }}</li>\n{%- endfor %}</ul>")
- >>> stream = tmpl.stream(seq=range(4))
- >>> stream.next()
- '<ul>'
- >>> stream.next()
- u'\n <li>1 - 0</li>'
- >>> stream.next()
- u'\n <li>2 - 1</li>'
- >>> stream.next()
- u'\n <li>3 - 2</li>'
- >>> stream.next()
- u'\n <li>4 - 3</li>'
- >>> stream.next()
- '</ul>'
-
-As you can see each iteration is threated as template event here. But also
-other tags trigger events. Basically every tag yields one event, the
-`print` tag too. The only exception is the variable substitution syntax which
-is inserted into the template text data.
-
-Because some protocols like `WSGI` flush after each iteration if passed as
-response iterable it's better to buffer some events internally. You can do
-this by enable buffering using `enable_buffering` and passing it the buffer
-size which must be greater than one:
-
-.. sourcecode:: pycon
-
- >>> stream.enable_buffering(size=3)
- >>> stream.next()
- u'<ul>\n <li>1 - 0</li>\n <li>2 - 1</li>'
- >>> stream.next()
- u'\n <li>3 - 2</li>\n <li>4 - 3</li></ul>'
-
-This will buffer 3 events before yielding. Disabling buffering works using the
-`disable_buffering` method. You can enable and disable buffering on the fly also
-if you have already iterated over that stream. To check if you are in buffered
-or unbuffered mode you can use the `.buffered` property:
-
-.. sourcecode:: pycon
-
- >>> stream.buffered
- False
- >>> stream.enable_buffering(20)
- >>> stream.buffered
- True
- >>> stream.disable_buffering()
- >>> stream.buffered
- False
-
-.. admonition:: Note
-
- Jinja uses buffering internally for some constructs like macros. A macro
- call is yielded as one event, independently of the internal structure.
-
- The same applies to recursive for loops and `{% filter %}` tags.
+++ /dev/null
-=============================
-Template Internationalization
-=============================
-
-If the application is configured for i18n, you can define translatable blocks
-for translators using the `trans` tag or the special underscore function:
-
-.. sourcecode:: jinja
-
- {% trans %}
- this is a translatable block
- {% endtrans %}
-
- {% trans "This is a translatable string" %}
-
- {{ _("This is a translatable string") }}
-
-The latter one is useful if you want translatable arguments for filters etc.
-If you want to use the ``_()`` syntax in an expression and have variables in
-the string you can add a substituation marker (``%s``) and use the `|format`
-filter to fill the slot:
-
-.. sourcecode:: jinja
-
- {{ _('Hello %s!')|format(username) }}
-
-If you have more than one substitution variable consider using the
-``{% trans %}`` tags or the `|dformat` filter, the latter however is new
-in Jinja 1.1.
-
-If you want to have plural forms too, use the `pluralize` block:
-
-.. sourcecode:: jinja
-
- {% trans users=users %}
- One user found.
- {% pluralize %}
- {{ users }} users found.
- {% endtrans %}
-
- {% trans first=(users|first).username|escape, user=users|length %}
- one user {{ first }} found.
- {% pluralize users %}
- {{ users }} users found, the first one is called {{ first }}.
- {% endtrans %}
-
-If you have multiple arguments, the first one is assumed to be the indicator (the
-number that is used to determine the correct singular or plural form. If you
-don't have the indicator variable on position 1 you have to tell the `pluralize`
-tag the correct variable name.
-
-Inside translatable blocks you cannot use blocks or expressions (however you can
-still use the ``raw`` block which will work as expected). The variable
-print syntax (``{{ variablename }}``) is the only way to insert the variables
-defined in the ``trans`` header. Filters must be applied in the header.
-
-.. admonition:: note
-
- Please make sure that you always use pluralize blocks where required.
- Many languages have more complex plural forms than the English language.
-
- Never try to workaround that issue by using something like this:
-
- .. sourcecode:: jinja
-
- {% if count != 1 %}
- {{ count }} users found.
- {% else %}
- one user found.
- {% endif %}
-
-*New in Jinja 1.1*: It's now possible to use the marker name as implicit
-default:
-
-.. sourcecode:: jinja
-
- instead of this version:
-
- {% trans username=username %}Hello {{ username }}!{% endtrans %}
-
- you can now write this:
-
- {% trans username %}Hello {{ username }}!{% endtrans %}
+++ /dev/null
-==============
-Test Functions
-==============
-
-In addition to filters, Jinja also supports test functions. Test functions
-always return either ``True`` or ``False``. Inside the template they are available
-using the `is` operator.
-
-Jinja comes with some builtin tests listed in the `designer documentation`_.
-
-Writing Test Functions
-======================
-
-Test functions look exactly like filters mentioned in the `filter documentation`_:
-
-.. sourcecode:: python
-
- def is_even():
- def wrapped(env, context, value):
- return value % 2 == 0
- return wrapped
-
-Now you have to register that test on an environment:
-
-.. sourcecode:: python
-
- env.tests['even'] = is_even
-
-.. _designer documentation: builtins.txt
-.. _filter documentation: filters.txt
+++ /dev/null
-===========
-Translators
-===========
-
-Jinja translates the template sourcecode into executable python code behind
-the secenes. This is done by the python translator which is currently the
-only shipped translator. Because the interface isn't stable it's also not
-recommended yet to write other translators. However for one of the next Jinja
-versions a JavaScript translator is planned which allows you to translate
-Jinja templates into executable JavaScript code.
projects / jinja2.git / commitdiff
