Question

我做了一些小型的Django项目，每次我都被Django模板语言的明显限制所震惊。就像一个随机的例子，我很震惊地得知，如果在模板的上下文中，我有一个变量条和一个dict 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”和“你的视图不应该有太多逻辑”类型的东西。

如果你把理想主义放在一边并选择实用主义，那么我认为Mako是一个不错的选择。我现在已经将它用于生产能力（主要用于速度，功率和动态继承）3年以上。它没有以任何方式失败或以其他方式烦人。

理想主义者是正确的，但有时你必须去寻找可行的东西而不是正确的东西。如果您不受Django模板引擎的限制，请使用它。如果你需要更多的力量，Mako和Jinja是不错的选择。

Django可以很容易地换出模板引擎，让大多数事情像以前一样工作： http://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alternative-template-language

Answer 2

在模板中执行任意代码不应被视为本身就是好事。利用此类功能通常表明您的架构已损坏。

也就是说，如果您阅读了Django文档，那么明确表示您应该随意使用，丢弃和替换您希望的任何组件。 Django是故意模块化的，事实上，两个最易于替换的组件是模板引擎和ORM。

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

Answer 3

我不使用jinja，Mako或其他任何原因的一个原因是，它可能无法通过django增强功能使您的应用程序成为未来的证明。

去年，Alex Gaynor提出了一个GSoc项目提案，要求快速加载模板。 - 然后它被撤回以支持NoSQL项目。

但是随着更多的核心开发人员和更快的票据清理，我会坚持django完全堆栈，完全知道，组件必须最终由本土的组件改变。

如果你真的在真棒python库上寻找胶水框架，包括你选择的那些，那么Flask就是out there。

Answer 4

addons.mozilla.org正在使用Django + Jinga：https://github.com/jbalogh/zamboni

不确定社区是否对Jinga皱眉，但很多人都喜欢它，作为一个例子。

Answer 5

如果您的意思是“应用”，而不是“项目”，并且它不是完全私人使用，我建议您不要更改模板引擎;它会使应用程序不太可能被其他人使用，因为它需要它们来改变一些核心设置，它可能会破坏它与其他应用程序或整个项目之间的交互。

Answer 6

你的例子让我想起了人们将PHP与html混合在一起的旧PHP时代。感觉真厉害。直到有一天，人们意识到这个烂摊子是不可维护的。

如果设计被切割成“功能”，那么设计师会理解它吗？它可能会惹恼他。

有没有理由我应该在我的Django应用中劝阻使用替代模板引擎？

6 个答案: