除了个人偏好的影响，我一直倾向于使用官方标准的实现，比如APACHE的XML 引擎Axis。好处就是可以获得尽可能好的兼容性(比如早期MFC对于Win3x的兼 容性就比其它的应用程序框架好，当然现在各种版本都很完善了)。SMARTY发 布之前我一直使用的是PEAR 中的Integrated Template eXtension。这个引擎和 PHPLIB template、Fast template几乎是兼容的，从模板的语法到对模板的处理 同出一辙：都是将模板读入内存然后调用parse()函数，用数据对预置的标记进 行替换。
下面看看SMARTY是怎么做的。接到request后，先判断是否第一次请求该url， 如果是，将该url所需的模板文件"编译"成php脚本，然后redirect；如果不是， 就是说该url的模板已经被"编译"过了，检查不需要重编译后可以马上redirect， 重编译条件可以自己设定为固定时限，默认的是模板文件被修改。
怎么样，看起来是不是有点眼熟？想起来了──这不就是JSP的原理嘛！的确， 这种"编译"用在PHP这样的解释性脚本引擎上显得匪夷所思，但是仔细想 想，JAVA不也是由JVM解释执行的吗？这就叫"没有做不到，只有想不到"。
既然谈到了JAVA，就再对PHP的未来发表一点看法。PHP官方网站上宣布了要 在2003年年底发布PHP5.0版。这个版本拥有很多崭新的特性：比如异常处理， 命名空间，更加面向对象等等。可以说越来越向JAVA靠拢，SMARTY也是新特 性之一，使得PHP更适用于大中型项目的开发。但是似乎离我当初选择它的原 因──灵巧易用──越来越远了。但就一个软件的生存周期来看，PHP正处在 成长期，开发者赋予它更多的功能，以期能胜任商业应用是利大于弊的。作为 PHP的忠实用户，肯定不希望PHP总是被人指责"能力不足"吧？
为什么选择SMARTY，仅仅因为它很像JSP？当然有更为充分的理由。首先，除 了第一次编译的成本比较高之外，只要不修改模板文件，编译好的cache脚本就 随时可用，省去了大量的parse()时间；其次SMARTY像PHP一样有丰富的函数 库，从统计字数到自动缩进、文字环绕以及正则表达式都可以直接使用；如果 觉得不够，比如需要数据结果集分页显示的功能，SMARTY还有很强的扩展能 力，可以通过插件的形式进行扩充。
事实胜于雄辩。我设计了一个测试程序，通过速度和开发难度这两个因素对比 了一下SMARTY和PHPLIB template，选PHPLIB template的原因是在patrick的 文章《在PHP世界中选择最合适的模板》中有一个PHPLIB template对Fast template 的竞赛，结果PHPLIB template大获全胜，这使得SMARTY有了一个很好的对 手。在测试之前，先谈一下在安装过程中需要注意的问题。
三、可能遇到的问题
在SMARTY的官方网站上，有详尽的用户手册，可以选择在线HTML和PDF格式 的版本。这里就不再涉及手册上已有的内容，只是把初次使用可能遇到的问题 做个解释。
