三、可能遇到的问题
在SMARTY的 官方网站上,有详尽的用户手册,可以选择在线HTML和PDF格式的版本。这里就不再涉及手册上已有的内容,只是把初次使用可能遇到的问题做个解释。
第一个问题就很要命:提示说找不到所需文件?并不是每一个人都按照SMARTY默认目录结构来写应用的。这里需要手工指定,假设目录结构如下:
就需要在index.php里指定目录结构:
$smart->template_dir = "smarty/templates/";
$smart->compile_dir = "smarty/templates_c/";
$smart->config_dir = "smarty/configs/";
$smart->cache_dir = "smarty/cache/";
第一个问题解决了,紧接着就是第二个:我刚用Dreamweaver生成的漂亮模板怎么不能用?并不是模板文件有什么问题,而是因为SMARTY默认的标记分隔符是{},不巧的是Javascript肯定包含这个标记。好在我们可以用任意字符当作分隔符,再加上这两句:
$smart->left_delimiter = "{/";
$smart->right_delimiter = "/}";
这下安装就基本完成,没问题了。
四、反衬和类比
先构思一下对测试的设计。主要的评比因素当然是速度了。为了进行速度测试,采取了算术平均数的作法。在测试页面中重复将页面生成N遍,再对比总页面生成时间。另一个重要因素是易用性(至于扩展性不用比较已经有结果了),所以使用的模板不能太小。我用的是我个人主页的的页面,一个用Firework+Dreamweaver生成的HTML文件,大小约7K。其中的变量设置也采取最常用的区块,在PHPLIB template里叫block,而SMARTY则称section。别小看这称呼的不同,易用性标准分两块:模板文件和脚本文件的语法是否简明易用。
下面就深入到测试中来。先看看两种模板文件的语法:蓝条左边是PHPLIB template的模板,右边属于SMARTY。个人偏好是不一样的,所以这里不作评论。着重对比一下脚本里的处理语句,先看PHPLIB template的:
$tpl->set_file('phplib', 'bigfile.htm');
$tpl->set_block('phplib', 'row', 'rows');
for ($j = 0; $j < 10; $j++){
$tpl->set_var('tag' ,"$j");
$tpl->parse('rows', 'row', true);
}
$tpl->parse('out', 'phplib');
$tpl->p('out');
下面是SMARTY的:
$smart->assign('row',$row);
$smart->display('bigfile.htm');
SMARTY只用了tags和row两个变量,而PHPLIB template则多了模板文件的handler,还有一个莫名其妙的out。说实在的这个out我当初学的时候就不知道为什么要存在,现在看起来,还是别扭。为什么SMARTY少那么多处理语句呢?答案是工作由引擎完成了。如果你喜欢钻研源程序,可以发现在Smarty_compiler.class.php里有一个名叫_compile_tag()的函数,由它负责把section这个标签转换成php语句。这不是一个普通的标签,它带有参数和数据,节省了脚本编程的工作量,而模板标签上的工作量相差又不大,可以判定在易用性上SMARTY高出一畴。
下面该轮到我们最关注的速度了,毕竟对于一个熟练的web开发者来说,掌握再困难的工具不过是时间问题,何况模板引擎这种学习曲线平缓的技术。而速度则是web应用程序的生命,尤其是模板引擎使用在并发访问量很大的站点上,这点就更重要了。测试开始前,我觉得PHPLIB template会在这一环节上胜出,因为它经历了很多次升级,已经基本没有什么bug,而且SMARTY的引擎个头太大,不像它的对手只有两个文件。
果然,测试结果如下图,PHPLIB template有25%的速度优势:
但不会一直这样,我又按了一次刷新,这次得到了不一样的结果:
PHPLIB基本没变化,但是SMARTY提高了25%的速度。继续刷新,得到的都是类似于第二次的结果:SMARTY比PHPLIB template 快上近10%。我想这就是编译型比解释型快的原理了。SMARTY引擎本身就很大,加上还要把模板编译成php文件,速度当然比不上小巧的PHPLIB template。但这只是第一次的情况。第二次接到请求的时候,SMARTY发现该模板已经被编译过了,于是最耗时的一步被跳过了,而对手还要按部就班地进行查找和替换工作。这是编译原理里讲到的很经典的"用空间换时间"例子。
五、结论
结论就是如果你已经爱上SMARTY了,那么还等什么呢?当然并不是说它就全能,就如同我用MVC模式来写我的个人网站,非但没有减少工作量,反而总是要为不同层次间的耦合劳神。
SMARTY不适合什么呢?举个手册里的经典例子:天气预报网站。我还想到一个:股市大盘。在这种网站上用SMARTY会由于经常的重编译而效率偏低,还是PHPLIB template更为适合。
本文并不是为了对比两种引擎,而是为了说明SMARTY的优势。使用它最有意义之处在于它是PHP新体系的一部份,作为一支独立的力量,除了.NET和JAVA ONE这两大体系之外,大中型web开发还有别的选择。这对于GNU项目来说,其意义无异于刘邓大军千里跃进大别山。
◎进入论坛网络编程版块参加讨论