在我的Django应用程序中,我是否应该劝阻使用替代模板引擎？

我做了一些小型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之外我唯一使用过的那个.

解决方法:

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

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

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

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

标签：python,django,templating,mako
来源： https://codeday.me/bug/20190721/1497131.html