Automated merge with ssh://team@pocoo.org/jinja2-main
[jinja2.git] / docs / switching.rst
1 Switching from other Template Engines
2 =====================================
3
4 .. highlight:: html+jinja
5
6 If you have used a different template engine in the past and want to swtich
7 to Jinja2 here is a small guide that shows the basic syntatic and semantic
8 changes between some common, similar text template engines for Python.
9
10 Jinja1
11 ------
12
13 Jinja2 is mostly compatible with Jinja1 in terms of API usage and template
14 syntax.  The differences between Jinja1 and 2 are explained in the following
15 list.
16
17 API
18 ~~~
19
20 Loaders
21     Jinja2 uses a different loader API.  Because the internal representation
22     of templates changed there is no longer support for external caching
23     systems such as memcached.  The memory consumed by templates is comparable
24     with regular Python modules now and external caching doesn't give any
25     advantage.  If you have used a custom loader in the past have a look at
26     the new :ref:`loader API <loaders>`.
27
28 Loading templates from strings
29     In the past it was possible to generate templates from a string with the
30     default environment configuration by using `jinja.from_string`.  Jinja2
31     provides a :class:`Template` class that can be used to do the same, but
32     with optional additional configuration.
33
34 Automatic unicode conversion
35     Jinja1 performed automatic conversion of bytestrings in a given encoding
36     into unicode objects.  This conversion is no longer implemented as it
37     was inconsistent as most libraries are using the regular Python ASCII
38     bytestring to Unicode conversion.  An application powered by Jinja2
39     *has to* use unicode internally everywhere or make sure that Jinja2 only
40     gets unicode strings passed.
41
42 i18n
43     Jinja1 used custom translators for internationalization.  i18n is now
44     available as Jinja2 extension and uses a simpler, more gettext friendly
45     interface and has support for babel.  For more details see
46     :ref:`i18n-extension`.
47
48 Internal methods
49     Jinja1 exposed a few internal methods on the environment object such
50     as `call_function`, `get_attribute` and others.  While they were marked
51     as being an internal method it was possible to override them.  Jinja2
52     doesn't have equivalent methods.
53
54 Sandbox
55     Jinja1 was running sandbox mode by default.  Few applications actually
56     used that feature so it became optional in Jinja2.  For more details
57     about the sandboxed execution see :class:`SandboxedEnvironment`.
58
59 Context
60     Jinja1 had a stacked context as storage for variables passed to the
61     environment.  In Jinja2 a similar object exists but it doesn't allow
62     modifications nor is it a singleton.  As inheritance is dynamic now
63     multiple context objects may exist during template evaluation.
64
65 Filters and Tests
66     Filters and tests are regular functions now.  It's no longer necessary
67     and allowed to use factory functions.
68
69
70 Templates
71 ~~~~~~~~~
72
73 Jinja2 has mostly the same syntax as Jinja1.  The only difference is that
74 assigning variables doesn't use `set` as keyword now.  The following
75 example shows a Jinja1 variable assignment::
76
77     {% set foo = 42 %}
78
79 In Jinja2 the `set` is ommited::
80
81     {% foo = 42 %}
82
83 Additionally macros require parentheses around the argument list now.
84
85 Jinja2 allows dynamic inheritance now and dynamic includes.  The old helper
86 function `rendertemplate` is gone now, `include` can be used instead.
87 Additionally includes no longer import macros and variable assignments, for
88 that the new `import` tag is used.  This concept is explained in the
89 :ref:`import` documentation.
90
91 Currently there is no support for the `recursive` modifier of for loops!
92
93
94 Django
95 ------
96
97 If you have previously worked with Django templates, you should find
98 Jinja2 very familiar.  In fact, most of the syntax elements look and
99 work the same.
100
101 However, Jinja2 provides some more syntax elements covered in the
102 documentation and some work a bit different.
103
104 This section covers the template changes.  As the API is fundamentally
105 different we won't cover it here.
106
107 Method Calls
108 ~~~~~~~~~~~~
109
110 In Django method calls work implicitly.  With Jinja2 you have to specify that
111 you want to call an object.  Thus this Django code::
112
113     {% for page in user.get_created_pages %}
114         ...
115     {% endfor %}
116     
117 will look like this in Jinja::
118
119     {% for page in user.get_created_pages() %}
120         ...
121     {% endfor %}
122
123 This allows you to pass variables to the function which is also used for macros
124 which is not possible in Django.
125
126 Conditions
127 ~~~~~~~~~~
128
129 In Django you can use the following constructs to check for equality::
130
131     {% ifequal foo "bar" %}
132         ...
133     {% else %}
134         ...
135     {% endifequal %}
136
137 In Jinja2 you can use the normal if statement in combination with operators::
138
139     {% if foo == 'bar' %}
140         ...
141     {% else %}
142         ...
143     {% endif %}
144
145 You can also have multiple elif branches in your template::
146
147     {% if something %}
148         ...
149     {% elif otherthing %}
150         ...
151     {% elif foothing %}
152         ...
153     {% else %}
154         ...
155     {% endif %}
156
157 Filter Arguments
158 ~~~~~~~~~~~~~~~~
159
160 Jinja2 provides more than one argument for filters.  Also the syntax for
161 argument passing is different.  A template that looks like this in Django::
162
163     {{ items|join:", " }}
164
165 looks like this in Jinja2::
166
167     {{ items|join(', ') }}
168
169 In fact it's a bit more verbose but it allows different types of arguments -
170 including variables - and more than one of them.
171
172 Tests
173 ~~~~~
174
175 In addition to filters there also are tests you can perform using the is
176 operator.  Here are some examples::
177
178     {% if user.user_id is odd %}
179         {{ user.username|e }} is odd
180     {% else %}
181         hmm. {{ user.username|e }} looks pretty normal
182     {% endif %}
183
184
185 Mako
186 ----
187
188 .. highlight:: html+mako
189
190 If you have used Mako so far and want to switch to Jinja2 you can configure
191 Jinja2 to look more like Mako:
192
193 .. sourcecode:: python
194
195     env = Environment('<%', '%>', '${', '}', '%')
196
197 Once the environment is configure like that Jinja2 should be able to interpret
198 a small subset of Mako templates.  Jinja2 does not support embedded Python code
199 so you would have to move that out of the template.  The syntax for defs (in
200 Jinja2 defs are called macros) and template inheritance is different too.  The
201 following Mako template::
202
203     <%inherit file="layout.html" />
204     <%def name="title()">Page Title</%def>
205     <ul>
206     % for item in list:
207         <li>${item}</li>
208     % endfor
209     </ul>
210
211 Looks like this in Jinja2 with the above configuration::
212
213     <% extends "layout.html" %>
214     <% block title %>Page Title<% endblock %>
215     <% block body %>
216     <ul>
217     % for item in list:
218         <li>${item}</li>
219     % endfor
220     </ul>
221     <% endblock %>