总体来说，模板引擎是一个"好东西"

作为一个PHP/Perl的程序员，许多模板引擎（fastTemplate, Smarty, Perl的 HTML::Template）的用户，以及我自己的(bTemplate ^[1] 的作者)，我讲这句话很多次了。

然而，在同事进行了长时间的讨论之后，我确信了大量的模板引擎（包括我自己写的）根本是错误的。 我想唯一的例外是Smarty ^[2]，虽然我认为它太庞大了，并且考虑到这篇文章的其余部分相当的没有观点。然而，就你为什么选择Smarty（或者类似的解决方案）有几个理由，这些将在文章后面探究。

这篇文章讨论模板的理论。我们将看到为什么大部分"模板引擎"是过于肥大，并且最终我们将回过头来看一个轻量级的，小巧快速的另类选择。

下载和授权

模板类和所有在本文中使用的例子能够在这里下载：template.zip ^[3]。你可以根据发布 ^[4]在 OSI ^[5] 的 MIT Open Source License使用这些文件中的代码。

一些关于模板引擎的背景知识

让我们首先研究一下模板引擎的背景知识。模板引擎被设计出来用于把商业逻辑（例如从数据库中获取数据或者计算贸易耗费）从数据的表现分离开来。模板引擎解决了两个主要问题：

1. 如何实现这种分离
2. 如何从HTML中分离"复杂"的php代码

这从理论上使得没有PHP经验的HTML设计者能够不看任何PHP代码的条件下修改站点的外观。

然而，模板系统也引入了一些复杂性。首先，我们现在有一个从多个文件得来的"页面"。典型的，你可能有一个主PHP页负责业务逻辑，一个外面的"布局"模板把整个站点的整体布局进行渲染，一个内部的内容特定的模板，一个数据库抽象层，以及模板引擎本身（这些可能是也可能不是由多个文件组成）。也有可能，一些人仅仅简单地在每个PHP页面的首尾处包含"头部"和"尾部"文件。

这产生的单个页面的文件数量是很可观的。然而，因为PHP解析器非常快，用到的文件数量可能不是那么重要除非你的站点流量很大。
然而，要记住模板系统引入了另外一个处理的层次。模板文件不仅仅是必须被包含，他们还必须被解析（取决于模板系统，这个行为有很多种方式来完成 —— 使用正则表达式，字符串替换，编译，词法分析，等等）。这就是为什么对模板进行测速变得流行起来：因为模板引擎使用各种方法来解析数据，它们中的一些比另外一些要快（而且，一些模板引擎提供了比其他引擎更加丰富的功能）。

模板引擎基础知识

简单地说，模板引擎利用了用C写的脚本语言（PHP）。在这些嵌入的脚本语言中，你有另外一个伪脚本语言（无论你的模板引擎支持何种标签）。某些提供了简单的变量改写和循环。另外一些呢，则提供了条件和嵌套循环。而再其他的呢（至少有Smarty）提供了一个PHP的比较大的子集的接口，以及一个缓冲层。

为什么我认为Smarty最接近于正确的方向？因为Smarty的目标是"把业务逻辑从表现中分离出来"而不是"PHP代码和HTML代码的分离"。这看上去区别不大，但是它正是要点所在。任何模板引擎的最终目标不应该是从HTML移除所有的逻辑。它应该是把表现逻辑从业务逻辑中分离出来。

有很多你仅仅需要逻辑来正确显示你的数据的例子。例如，你的业务逻辑是从你的数据库中获取一个用户列表。你的表现逻辑可能是把用户列表用3列显示。可能修改用户列表函数使得它返回3个数组是很笨的办法。毕竟函数不应该关心数据接下来要怎么处理这样的事情。然而，在你的模板文件中缺少一些逻辑，那些正是你要做的事情。

在这点上Smarty是正确的（使得你利用PHP的很多东西），但是仍然有许多问题。基本上，它仅仅提供了一个以新语法访问PHP的接口。以那开始，它看上去不那么聪明了。是不是事实上写 {foreach --args} 比 <? foreach --args ?> 更加简单？如果你认为这样简单一些，问问你自己是不是在包含一个巨大的模板库来到成这种分离时能够看到真正的意义要更加简单一些。诚然，Smarty提供了许多其他很好的特性，但是看上去这些益处能够在不用承担包含Smarty类库的情况下也能获得。

别样的解决方案

我主要要鼓吹的一个解决方案是一个使用PHP代码作为它的原生脚本语言的"模板引擎"。我知道这以前有人做过。而且当我第一次看到的时候，我想，"为什么要这样做？"，然而我在考虑过我同事的论据之后，并且实现了一个直接使用PHP代码仍然实现了把业务逻辑和表现逻辑分离的最终目标的模板系统时（只用了大约25行代码，不包括注释），我意识到了好处所在。

这个系统给像我们这样的开发者提供了对PHP核心函数的访问权利，我们能够使用他们来格式化输出——像

PHP 开发程序加速运行探索之慢代码优化方法 用PHP制作zip压缩程序