也谈模板

　我不喜欢php模板，而且一直对模板报有抵触情绪。虽然php的模板多种多样，但是很难让我提起兴趣。听说奶瓶要写模板的扩展模块，我很感兴趣，但是并不抱着很大的希望。下面我仅仅从我的经验中阐述模板的作用以及模板适合做什么。

　　上次看到一篇帖子说php脚本就是模板，虽然我不赞同他的其他论述，但对这一点还是认同的。在编程语言中，“模板”这个词我第一次见到是在学习C++的时候，能使用别人写好的模板轻松创建出自己需要的数据结构。各人感觉这种模板和现在的各种脚本语言很像，我们这些php脚本程序员都是在使用前人写好的模板轻松的创建程序。我想即使是C语言的程序员也是在用那些B语言程序员开发的模板吧。广义的看，我们使用的SQL甚至HTML都可以看作模板。这体现出模板的两个作用，其一是简化编程，提高了开发效率；其二是避免了我们重复前人的工作，从另一个方面提高了开发效率。

　　还有一些模板很有意思，我经常在一些blog程序中见到他们。他们为客户提供了可以随意定义个人空间样式的方法。简陋一点的会直接让用户编辑css文件甚至html代码，高级一点的会有一个向导来辅助用户编辑样式，甚至会做成在线编辑器的形式。这种模板就会引起一种矛盾：如何在用户体验和自由度上权衡。对于一些对页面质量要求高的新手，即使提供了在线编辑器，还会让他们感到焦头烂额，看似简单的页面效果却始终无法搞定。我的一个亲戚就曾经遇到这样一件事情，他的公司将自己的网站外包出去做，结果就让一个在线编辑器搞得时不时就报错。最后人家叫他先用Dreamweaver编辑再复制代码，公司的网站本来更新就不多且结构简单，感觉这样还不如使用静态页面。当然，我相信这仅仅是个极端的例子，但是后来遇到的一些模板却将此种情况“发扬光大”。我看到很多模板打着简化开发的旗号推销自己，于是就去查看他们的手册。拿smarty的模板来说，首先需要肯定的是他很明确的区分了不同的用户，哪些是给php程序员用的，哪些则是给前端开发者使用的，在手册中都写得很清楚，而且它在某些功能的实现上效率的确很高。但是还有一个问题，无论是哪种用户在使用smarty的时候都要学习一种新的模板语言。我常常问，如果同一种功能可以使用php来实现，为什么要使用smarty？就好比我已经习惯了从小学一年级就学会的拼音输入法，有什么理由去花更多的时间去学习五笔字型输入法？当然，好在smarty的扩展性能还算强大，其他一些CMS捆绑的专用模板与之相比较起来就显得捉襟见肘了。我最近使用过的CMS似乎都流行采用模板来控制页面，有的系统甚至可以控制后台页面的样式。如果是普通开源的CMS我们一般可以通过嵌入php代码的方法扩展其功能，但是如果他采用了模板就麻烦了。对于我现在所在的这种做网站外包的单位很难有时间去分析那些模板机能去修改他们的模板内核，甚至有些代码是被加密过的。（当然并非完全没有办法扩展，可以采用javascript调用的方法只不过没有直接用php代码的直接简单）也有些模板可以嵌入php代码，这看起来不错，功能可以通过模板扩展了，比如织梦的模板。这带来了另一个问题，由于编辑大部分模板最终还是要编辑html代码，大部分最终用户都会感觉这个过程过于复杂而交给外包公司去做，外包公司又会感觉使用模板的系统功能不易于扩展很难达到客户的要求而挠头。个人认为很多随CMS程序捆绑的模板花费了很大的周折做的往往是画蛇添足的事情。

　　我认为在制作模板程序之前，认清楚谁将要使用你的模板程序这点很重要。如果你的模板要给一个php程序员使用，那我感觉还是开发成类库（或者函数库）的形式比较好，模板写成可以含php标记的（我个人喜欢混排）形式。如果给客户端页面制作人员开发的，个人感觉还是使用符合xml标准的模板比较好。我曾经提出过采用xslt模板，当时有人说“不是一回事”，我觉得如果让xslt在服务器端执行（目前php有这个扩展）我感觉也都差不多了，况且这种模板对熟悉html的人来说比php要简单很多。若是给终端用户开发模板就比较复杂了，终端用户的要求一般会千奇百怪，当然我们没有必要去实现那些成本上划不来的功能（如果不考虑成本也许我们会为某个客户开发一款浏览器或客户端应用程序）。最好是能够有一个简单的向导来指导用户定义自己的模板，同时规避那些威胁系统安全的功能，隐藏那些容易引发用户浮想联翩的功能（滥用在线编辑器有可能导致你的项目永远达不到用户的要求）。

　　这篇文章中很少谈技术，没什么可总结的。我知道拥护模板技术的人不少，我曾因此而在找工作的时候碰壁。请大家提意见吧，我洗耳恭听。