有什么理由不让我在Django应用程序中使用替代模板引擎？

Question

我做过一些小的ishdjango项目，每次我都被Django模板语言明显的局限性所震撼。作为一个随机的例子，我震惊地发现，如果在一个模板的上下文中，我有一个变量条和一个dict-foo，除非我自己编写过滤器，否则我无法访问foo[bar]。在

我读过这样做的原因是因为Django是为那些设计页面的人不是程序员的环境而创建的。我明白。在

但我觉得这对我来说不是问题。为什么你要用一些像Python那样的任意表达式，而不是像magango这样的语言来执行呢？在

不久前我有机会利用Mako进行学校项目，我真的很喜欢它的力量。例如，作为项目的一部分，我们必须制作一个大表，在那里构建每一行和每一个单元格都相当复杂。但是，我可以让我的模板看起来像：

<table>
    % for foo in foos:
        ${makerow(row)}
    % endfor
</table>

<%def name="makerow(row)">
    <tr>
        # Blah blah blah (possibly a call to makecell somewhere)
    </tr>
</%def>

也许这违反了表达和逻辑的分离，但孩子们，它是好的和干净的。子程序！抽象！好东西。在

还有一个后续问题：如果Django社区不反对使用另一种模板语言，有人有什么建议吗？就像我说的，我真的很喜欢Mako，但实际上它是除了Django之外我唯一用过的

Answer 1

在模板中执行任意代码不应该被认为是一件固有的好事。利用这些功能通常是您的架构被破坏的标志。在

也就是说，如果您阅读了Django文档，它明确地指出您可以随意使用、丢弃和替换任何您想要的组件。Django是有意模块化的，事实上，两个最普通的可替换组件是模板引擎和ORM。在

如果您想使用Mako而不是Django模板引擎，只需使用Mako。在

Answer 2

我不想使用jinja、Mako或其他任何东西的一个原因是，它可能无法让你的应用程序在django增强后经得起未来的考验。在

去年有一个由alexgaynor提出的GSoc项目提案，旨在加快模板加载速度。-后来，为了支持NoSQL项目，它被收回了。在

但随着更多的核心开发人员和更快的清理工作，我将坚持使用django的完整堆栈，我非常清楚，组件最终必须由自己开发的组件进行更改。在

如果您真的要在很棒的python库上寻找一个glue框架，包括您选择的库，Flask是out there。在

Answer 3

老实说，我没有仔细阅读这些回复。但我猜这是很多“模板中没有python”和“视图不应该有太多逻辑”类型的东西。在

如果你抛开理想主义而选择实用主义，那么我认为Mako是个不错的选择。我已经在生产能力中使用了3年多了（主要用于速度、功率和动态继承）。它没有失败，也没有以任何方式让人恼火。在

理想主义者是对的，但有时你不得不去追求可行的与正确的。如果您不受Django模板引擎的限制，请使用它。如果你需要更多的能量，Mako和Jinja是不错的选择。在

Django使替换模板引擎变得非常容易，并使大多数功能保持以前的工作状态： http://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alternative-template-language