关于PhpPatterns，我最近阅读了一篇关于PHP中的模板引擎的文章。正如它所说（我的解释），它激怒了我：
- “模板引擎是个坏主意”
- “使用PHP原生模板可能是个好主意”
- “模板引擎……不值得他们写的文字在”
好的，这实际上是文章的直接引用。我立即对此提出异议——我所做的每件事都使用Smarty，而且这样做的决定并不是轻易做出的。事实上，多年来我一直在提倡使用一种或另一种语言的模板引擎，我担任过各种职位；我认为它们是大于几页的项目的必备工具。为什么？
- 混合使用多种语言会导致效率低下。当我在编程时，使用多达四种不同的语言进行编写是非常低效的：PHP或Perl、X/HTML、CSS和Javascript。在同一个文件中在它们之间切换既麻烦又混乱，并且试图找到隐藏在引号中的HTML实体可能是一场噩梦，即使在heredocs中完成也是如此。将语言分成不同的文件似乎不仅自然，而且必不可少。
- 视图包含它们自己的逻辑。在MVC模式中，最终的网页View可能依赖于通过Controller传递给它的数据；然而，这并不意味着我想要像PHP或Perl这样的语言的全部功能来做到这一点。我应该只做简单的逻辑或循环构造——而完整的脚本语言就太过分了。（不过，我确实认识到Smarty等模板引擎是使用PHP编写的，因此无论如何都会调用该语言。我在这里所说的是用于编写模板的语言。）
- 抽象和安全。模板页面上泄露的内部信息越少越好。出于安全目的，我可能不希望客户能够知道如何数据到达页面，而只希望他们知道哪些数据可用。此外，如果此数据足够抽象，则可以将任意数量的后端连接到页面以生成输出。
所以，阅读上述文章真的让我感到困惑。然而，它也让我开始思考。提出的一个问题是PHP可以用作您的模板语言。虽然我能理解为什么这可能是可取的——从负载问题到灵活性的一切——但我也觉得这没有提供足够的抽象。
根据我对ThePragmaticProgrammer的理解，在我看来使用PHP在两个基本层面上是低效的：
- 领域语言。实用程序员建议应该使用一种语言的子集，或者开发全新的迷你语言，与手头的领域对话。例如，您可能想使用锋利的工具打开罐头；一把斧头会杀伤力过大，但一把刀可能会很好用。用PHP来描述模板就像用斧子开罐头一样；它会完成工作，但它也可能把一切搞得一团糟，仅仅是因为它对工作来说太锋利了。
- 元数据。元数据是关于数据的数据；它是关于数据的数据。在我看来，模板描述了它们正在交流的数据；编译后的模板实际上包含了数据。在这方面，再次将PHP放入脚本中是矫枉过正，因为这样做不仅仅给出了一些关于数据是什么的提示。
这篇文章的作者还为网页设计师教授PHP提供了一个案例——这种语言很容易上手，他们通常可以像模板语言一样轻松地学习它，如果不是更容易的话。我在一定程度上同意……但我的经验表明，网页设计师通常都在与HTML作斗争，更不用说PHP了。（注意：我在这方面的经验并不丰富，而且我确信这是夸大其词。）我发现通常最简单的方法是提供示例模板，解释有趣的非HTML内容可以做什么，然后让他们从那里去。使用这种方法，他们不需要学习任何新东西——他们只需使用占位符。
不过，我认为作者提出了一些很好的观点。我希望他能在完全抨击模板引擎之前，对人们选择模板引擎以及使用它们所带来的好处进行更多研究。当然，这篇文章也有点过时了；它是两年前写的，PHP及其许多模板引擎的世界已经发生了很大变化。我很好奇他们今天是否会有同样的感觉。
我？我下定决心了——在我的情况下，好处远远超过相关的任何成本。在未来的几年里，我将使用模板引擎，尤其是Smarty。
