Flask 中的设计决策

某个模板引擎

Flask 在模板引擎上做了决定： Jinja2 。为什么 Flask 没有一个即插的模板引擎 接口？显然，你可以使用一个不同的模板引擎，但是 Flask 仍然会为你配置 Jinja2 。虽然 Jinja2 总是 配置的限制可能会消失，但绑定一个模板引擎并使用 的决策不会。

模板引擎与编程语言类似，每个模板引擎都有特定的理解事物工作的方式。表面上， 它们以相同方式工作：你给引擎一个变量的集合让它为模板求值，并返回一个字符 串。

然而，关于相同点的论述结束了。例如 Jinja2 有一个全面的过滤器系统，一个可靠 的模板继承方式，可以从模板内和 Python 代码内使用复用块（宏）的支持，对所有 操作使用 Unicode，支持迭代模板渲染，可配置的语法等等。其它的引擎，一个类似 Genshi——基于 XML 流求值的引擎，模板继承要考虑 XPath 可用性等等。而 Mako 像 对待 Python 模块一样处理模板。

当把一个模板引擎跟一个应用或框架联系到一起，就不只是渲染模板了。比如， Flask 使用 Jinja2 全面的自动转义支持。同样，也提供了从 Jinja2 模板中 访问宏的途径。

不去掉模板引擎的独特特性的模板抽象层是一门对自身的科学，也是像 Flask 的微框架的巨大事业。

此外，扩展也可以简易地依赖于一个现有的模板语言。你可以简单地使用你自己的 模板语言，而扩展会始终依赖于 Jinja 本身。