我应该使用 Mako 进行模板化吗？
我一直在考虑模板解决方案，尽管我的选择是在 Mako 和 Genshi 之间。我发现 Genshi 中的模板有点丑陋，所以我更多地转向 Mako。
我想知道：Mako 允许嵌入 Python 代码有什么好处？对于普通人来说有多方便？
如果没有嵌入 Python 代码，模板是否就足够了？
I've been considering a templating solution, although my choices are between Mako and Genshi. I find templating in Genshi a bit ugly, so I'm shifting more towards Mako.
I've gone to wonder: what is so good about the fact that Mako allows embedded Python code? How is it convenient for the average joe?
Wouldn't templating JUST suffice without having embedded Python code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
正如 mako 主页 指出的那样，Mako 的优势非常明显：速度极快，任何熟悉 Python 的人都会立即熟悉在语法和功能方面。
Genshi 选择“解释”而不是提前生成 Python 代码（根据他们的 FAQ，这是为了清楚地显示错误消息）以及对 Python 的“敬而远之”方法（例如，使用 xpath 作为选择器，xinclude 而不是继承等），因此对于不懂 Python 但精通 XML 的人来说可能更自然。
那么你的“观众”是什么？如果是 Python 程序员，我建议 Mako（为了速度和熟悉度）；如果 XML 专家对 Python 感到不舒服，Genshi 可能更适合（因为“与 Python 保持一定距离”的方法并且更接近 XML 文化）。
你提到“普通的 Joe”，但 Joe 不了解 Python 并且 xpath 对他来说是一个深深的黑暗之谜；如果那确实是您的受众，那么其他模板系统（例如 Django 的）实际上可能更适合（帮助他避免陷入麻烦；-）。
As the mako homepage points out, Mako's advantages are pretty clear: insanely fast, instantly familiar to anyone who's handy with Python in terms of both syntax and features.
Genshi chooses "interpretation" instead of ahead-of-time Python code generation (according to their FAQ, that's for clarity of error messages) and an "arm's length" approach to Python (e.g. by using xpath for selectors, xinclude instead of inheritance, etc) so it might be more natural to people who know no Python but are very competent with XML.
So what's your "audience"? If Python programmers, I suggest Mako (for speed and familiarity); if XML experts that are uncomfortable with Python, Genshi might be a better fit (for "arm's length from Python" approach and closer match to XML culture).
You mention "the average Joe", but Joe doesn't know Python AND xpath is a deep dark mystery to him; if THAT was really your audience, other templating systems such as Django's might actually be a better fit (help him to avoid getting in trouble;-).
仅当您的模板语言具有足够的逻辑功能时，它本身本质上就是一种脚本语言。此时，您可能已经使用了 Python。
更多涉及的站点通常需要复杂的表示逻辑和重要的模板化结构，例如在不同位置/页面中重复的部分和递归树。如果您的模板语言将您的双手绑在背后，那么这就不好玩了，因为它采取了“模板中的代码是坏的”的宗教立场。
然后，您最终只能在 Python 业务逻辑中编写表示帮助器函数，这比您开始时所需要的表示和应用程序逻辑的混合更糟糕。因为不相信你能有品味地使用它而剥夺你权力的语言是蹩脚的。
Only if your templating language has enough logical functionality that it is essentially a scripting language in itself. At which point, you might just as well have used Python.
More involved sites often need complex presentation logic and non-trivial templated structures like sections repeated in different places/pages and recursive trees. This is no fun if your templating language ties your hands behind your back because it takes the religious position that "code in template are BAD".
Then you just end up writing presentation helper functions in your Python business logic, which is a worse blending of presentation and application logic than you had to start with. Languages that take power away from you because they don't trust you to use it tastefully are lame.
这似乎有点宗教问题。 Django 模板采取强硬路线：模板中没有代码。他们这样做是因为他们作为商店中使用的系统的历史，编写代码的人和创建页面的人之间有明显的区别。其他人（也许是您）不会做出如此明确的区分，并且会觉得在布局和逻辑之间有更灵活的界限会更舒服。
这确实取决于品味问题。
This seems to be a bit of a religious issue. Django templates take a hard line: no code in templates. They do this because of their history as a system used in shops where there's a clear separation between those who write code and those who create pages. Others (perhaps you) don't make such a clear distinction, and would feel more comfortable having a more flexible line between layout and logic.
It really comes down to a matter of taste.
Genshi 是为生成 xml 文档而设计的（读作：有偏差的、优化的）（即使它确实提供了对生成任何类型的文本文档的支持）。 Mako 和 Django 模板被视为通用文本模板系统。 Evoque 也是如此，但有一个根本区别，它的设计选择只允许 python 表达式< /em> 在模板中，即没有 python 语句。
这样做的一个重要的最终结果是，Evoque 能够在沙箱中执行模板评估 - 即您可以安全地向不受信任的用户提供对模板源代码的写入访问权限 - 对于也允许嵌入的模板引擎来说，这一功能实际上是不可能的python 语句。哦，虽然在直接功能比较中没有丢失任何东西，但 Evoque 在某些情况下实际上比 Mako 更快，而且它也可以在 Python 3 上运行。
Genshi is conceived (read: biased, optimized) for generation of xml docs (even if it does offer support for generating any kind of text document). Mako and Django templates are conceived as generic text templating system. Evoque also, but with one fundamental difference that it makes the design choice to only allow python expressions in templates i.e. no python statements.
One important net result of this is that Evoque is able to execute template evaluation in a sandbox -- i.e. you could safely give untrusted users write-access to a template's source code -- a feature that is virtually impossible for template engines that also allow embedding of python statements. Oh, and while not losing out any in a direct feature comparison, Evoque is in some cases actually faster than Mako, and it also runs on Python 3.
您可以约束自己不要在模板中注入任何 Python 代码，除非它确实是完成工作的最后手段。我在 Django 模板中遇到了类似的问题，我必须做一些认真的 CSS 练习来显示我的内容。如果我可以在模板中使用一些 Python 代码，那就更好了。
You could discipline yourself to not inject any Python code within the template unless it's really the last resort to get the job done. I have faced a similar issue with Django's template where I have to do some serious CSS gymnastics to display my content. If I could have used some Python code in the template, it would have been better.