总体来说，模板引擎是一个"好东西"
作为一个PHP/Perl的程序员，许多模板引擎（fastTemplate, Smarty, Perl的 HTML::Template）的用户，以及我自己的(bTemplate [1] 的作者)，我讲这句话很多次了。
然而，在同事进行了长时间的讨论之后，我确信了大量的模板引擎（包括我自己写的）根本是错误的。 我想唯一的例外是Smarty [2]，虽然我认为它太庞大了，并且考虑到这篇文章的其余部分相当的没有观点。然而，就你为什么选择Smarty（或者类似的解决方案）有几个理由，这些将在文章后面探究。
这篇文章讨论模板的理论。我们将看到为什么大部分"模板引擎"是过于肥大，并且最终我们将回过头来看一个轻量级的，小巧快速的另类选择。
模板类和所有在本文中使用的例子能够在这里下载：template.zip [3]。你可以根据发布 [4]在 OSI [5] 的 MIT Open Source License使用这些文件中的代码。
让我们首先研究一下模板引擎的背景知识。模板引擎被设计出来用于把商业逻辑（例如从数据库中获取数据或者计算贸易耗费）从数据的表现分离开来。模板引擎解决了两个主要问题：
这从理论上使得没有PHP经验的HTML设计者能够不看任何PHP代码的条件下修改站点的外观。
然而，模板系统也引入了一些复杂性。首先，我们现在有一个从多个文件得来的"页面"。典型的，你可能有一个主PHP页负责业务逻辑，一个外面的"布局"模板把整个站点的整体布局进行渲染，一个内部的内容特定的模板，一个数据库抽象层，以及模板引擎本身（这些可能是也可能不是由多个文件组成）。也有可能，一些人仅仅简单地在每个PHP页面的首尾处包含"头部"和"尾部"文件。
这产生的单个页面的文件数量是很可观的。然而，因为PHP解析器非常快，用到的文件数量可能不是那么重要除非你的站点流量很大。
然而，要记住模板系统引入了另外一个处理的层次。模板文件不仅仅是必须被包含，他们还必须被解析（取决于模板系统，这个行为有很多种方式来完成 —— 使用正则表达式，字符串替换，编译，词法分析，等等）。这就是为什么对模板进行测速变得流行起来：因为模板引擎使用各种方法来解析数据，它们中的一些比另外一些要快（而且，一些模板引擎提供了比其他引擎更加丰富的功能）。
简单地说，模板引擎利用了用C写的脚本语言（PHP）。在这些嵌入的脚本语言中，你有另外一个伪脚本语言（无论你的模板引擎支持何种标签）。某些提供了简单的变量改写和循环。另外一些呢，则提供了条件和嵌套循环。而再其他的呢（至少有Smarty）提供了一个PHP的比较大的子集的接口，以及一个缓冲层。
为什么我认为Smarty最接近于正确的方向？因为Smarty的目标是"把业务逻辑从表现中分离出来"而不是"PHP代码和HTML代码的分离"。这看上去区别不大，但是它正是要点所在。任何模板引擎的最终目标不应该是从HTML移除所有的逻辑。它应该是把表现逻辑从业务逻辑中分离出来。
有很多你仅仅需要逻辑来正确显示你的数据的例子。例如，你的业务逻辑是从你的数据库中获取一个用户列表。你的表现逻辑可能是把用户列表用3列显示。可能修改用户列表函数使得它返回3个数组是很笨的办法。究竟函数不应该关心数据接下来要怎么处理这样的事情。然而，在你的模板文件中缺少一些逻辑，那些正是你要做的事情。
在这点上Smarty是正确的（使得你利用PHP的很多东西），但是仍然有许多问题。基本上，它仅仅提供了一个以新语法访问PHP的接口。以那开始，它看上去不那么聪明了。是不是事实上写
评论加载中…
 |