@@ -96,18 +96,18 @@ is ambiguous.
96
96
One Template Engine
97
97
-------------------
98
98
99
- Flask decides on one template engine: Jinja2 . Why doesn't Flask have a
99
+ Flask decides on one template engine: Jinja . Why doesn't Flask have a
100
100
pluggable template engine interface? You can obviously use a different
101
- template engine, but Flask will still configure Jinja2 for you. While
102
- that limitation that Jinja2 is *always * configured will probably go away,
101
+ template engine, but Flask will still configure Jinja for you. While
102
+ that limitation that Jinja is *always * configured will probably go away,
103
103
the decision to bundle one template engine and use that will not.
104
104
105
105
Template engines are like programming languages and each of those engines
106
106
has a certain understanding about how things work. On the surface they
107
107
all work the same: you tell the engine to evaluate a template with a set
108
108
of variables and take the return value as string.
109
109
110
- But that's about where similarities end. Jinja2 for example has an
110
+ But that's about where similarities end. Jinja for example has an
111
111
extensive filter system, a certain way to do template inheritance,
112
112
support for reusable blocks (macros) that can be used from inside
113
113
templates and also from Python code, supports iterative template
@@ -118,8 +118,8 @@ other hand treats templates similar to Python modules.
118
118
119
119
When it comes to connecting a template engine with an application or
120
120
framework there is more than just rendering templates. For instance,
121
- Flask uses Jinja2 's extensive autoescaping support. Also it provides
122
- ways to access macros from Jinja2 templates.
121
+ Flask uses Jinja 's extensive autoescaping support. Also it provides
122
+ ways to access macros from Jinja templates.
123
123
124
124
A template abstraction layer that would not take the unique features of
125
125
the template engines away is a science on its own and a too large
@@ -150,7 +150,7 @@ authentication technologies, and more. Flask may be "micro", but it's ready for
150
150
production use on a variety of needs.
151
151
152
152
Why does Flask call itself a microframework and yet it depends on two
153
- libraries (namely Werkzeug and Jinja2 ). Why shouldn't it? If we look
153
+ libraries (namely Werkzeug and Jinja ). Why shouldn't it? If we look
154
154
over to the Ruby side of web development there we have a protocol very
155
155
similar to WSGI. Just that it's called Rack there, but besides that it
156
156
looks very much like a WSGI rendition for Ruby. But nearly all
@@ -208,7 +208,7 @@ What Flask is, What Flask is Not
208
208
209
209
Flask will never have a database layer. It will not have a form library
210
210
or anything else in that direction. Flask itself just bridges to Werkzeug
211
- to implement a proper WSGI application and to Jinja2 to handle templating.
211
+ to implement a proper WSGI application and to Jinja to handle templating.
212
212
It also binds to a few common standard library packages such as logging.
213
213
Everything else is up for extensions.
214
214
0 commit comments