python - 是否有理由劝阻我在我的 Django 应用程序中使用替代模板引擎？

Question

我做过一些小型的 Django 项目，每次我都对 Django 模板语言的明显局限性感到震惊。举一个随机的例子，我很震惊地得知，如果在模板的上下文中，我有一个变量 bar 和一个字典 foo，我将无法访问 foo[bar]，除非我编写自己的过滤器来执行此操作。

我读到这是因为 Django 是为设计页面的人不是程序员的环境创建的。我明白那个。

但假设这对我来说不是问题。为什么我应该坚持使用 Django 的模板语言，而不是切换到更强大的东西，比如 Mako(你甚至可以在其中执行任意 Python 表达式)？

不久前，我有机会在一个学校项目中使用 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

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

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

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

Django 使更换模板引擎变得非常容易，并使大多数事情像以前一样工作: http://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alternative-template-language