千万不要人云亦云的说这个好那个不好，选择模板之前最好先应该搞清楚模板的真正目的是什么？ 简单地说，模板的核心目的就是一个 team work。主要的作用方式有两种：
1、分离HTML和PHP使网页设计师和PHP程序员合作更加愉快。
2、分离显示逻辑和事物逻辑，使得核心事务逻辑的变更和应用程序的扩展更加容易和灵活，也就是说使得程序员之间合作更加愉快。（这一点经常被人们忽视或者误解，总以为把PHP从HTML中弄出去就叫分离显示逻辑和事物逻辑了，如果这样当初又何苦让PHP和html 混在一起呢？）
搞清楚这个模板的真正目的是什么，就容易做出正确的选择了。
如果只有你一个php程序员但是需要和其他的网页设计人员一起协同工作，那么选择能够分离HTML和PHP的模板就可以了，phplib （现在好像集成到 Pear 里面了 http://pear.php.net/package/HTML_Template_PHPLIB）或者
FastTemplate 都是这样的东西，很简单容易上手。
如果你的网站界面比较丑陋并且主要由程序员来完成，但是功能比较复杂更需要强大的扩展功能，需要分离各个层次包括显示逻辑，那么不要用什么特别的东西，PHP本身就是最好的模板了。要注意的是在这种情况下，你要非常认真的设计你的程序，始终记住要分离的不是PHP和 html 而是事务逻辑(business logic )和显示逻辑(presentation logic)。这也是为什么我一直对于Smarty 这种东西非常的抵触， 因为这个 Smarty 的语法太复杂了太强大了， 几乎重新发明了一种脚本语言东西， （即使是PHP的程序员也要重新学习它）。更让人费解的是 这种脚本 越是强大，越容易让人将事务逻辑(business logic )和显示逻辑(presentation logic)混在一起， 破坏了模板的初衷。
如果你既想HTML和PHP分离，得到更好的视觉设计，又想整个系统有非常强大的扩展能力能够适应html,xml,wml各种界面，而且不用去学习复杂的语法的同时提供较高的运行效率，那么这就是一个相当有挑战性的问题了。坏消息是目前还没有一个成熟的模板真正能够达到这样的要求，好消息是完成这样的一个模板并不是很难，如果你尝试过Zope或者是ColdFusion就会发现这种模板的影子，
TagActionDispatcher是一个标准的ActionDispatcher类的实现，它支持访问基本模板标签。TagActionDispatcher类支持相同的ActionObjects集合和ViewResourcesConfig属性作为默认的ActionDispatcher。TagActionDispatcher类能被用在带有或没有带有模板标签系统上，尽管由于它的额外处理会造成小的性能下降。
模板标签库是PHP。MVC框架结构的子系统，模板标签库联合TagActionDispatcher一起工作来支持一些简单的模板标签。
下面的图表显示了PHP。MVC模板标签系统的总揽。左边展示的是模板标签系统的程序流程。右边是TagActionDispatcher的程序流程，还有标签模板是怎样使这些类进行交互。
1、初始化
当控制器传递控制到达TagActionDispatcher，一些初始化触发去设置ActionObjects和ViewResourcesConfig属性为了使用我们的模板:
从request中重新获得$form，$errors和$data对象，如果这些对象中的任意一个已经在之前被创建(比如在Action类中)，那么对象现在将在资源模板中不可见，否则对象将被设置为NULL。
重新获得ViewResourcesConfig对象的参考，它包含了配置参数。
设置在ViewResourcesConfig参数中指向模板源文件和编译的模板文件的路径。
2、设置标签页面
模板源文件的扩展名(可能是"。ssp")被用来和ViewResourcesConfig-＞tagFlagStr参数相比较来决定是否这个页面需要处理，否则页面将被处理为标准(无标签)模板文件。我们能在view-resources元素中配置标签文件扩展名，就像这样:
＜view-resources
．．．
tagFlagStr = "。ssp"
tagFlagCnt = "-4"
．．．
＜/view-resources＞
tagFlagStr指示了标签模板源文件能被预处理，比如:myPage。ssp。这个扩展名触发标签处理。属性tagFlagCnt定义了文件名结尾的字符数，包括"。"(xxxYyy。ssp)。据个例子，-4代表源文件名最后4个字符。默认值是。ssp和-4，因此如果我们使用一个模板文件名像myPage。ssp，我们不需要设置这些参数。
3、处理标签文件
模板标签系统决定是否运行标签处理器，要根据ViewResourcesConfig-＞processTags属性。如果这个属性为真，模板页(及它所包含的页)将被标签处理器类所处理，否则标签处理器不会被调用。开发者只要将它在开发中将其设置为真即可，假则不处理。但要注意的是当processTags属性设置为真，修改过的标签页才会被编译(这依赖于compileAll属性设置)。我们能定义processTags属性在view-resources元素，就像这样:
作为流行的 Web 编程语言， PHP 的最大优势就是速度。
PHP4 已经在这方面做的非常好了，你几乎找不到比它更快的脚本编程语言了。但是如果你的应用负荷很大，而带宽又比较小，或者有其他的瓶颈影响你的服务器性能，那么，你不妨试试笔者为你开出的几个药方，看看是否灵验。
一、代码优化
一谈到代码优化，或许你想到的就是整齐明了的代码，但是本文的意思却不是在此，因为如果要寻求速度的话，就要对PHP 源码作相应的调整。一般说来就是去掉多余的注释，让代码不可读。但是这对于一个具有良好素养的程序员来说，简直就是不可思议的。好在Zend Technologies 公司发布了 Zend 优化引擎可以帮助你做到这一点。它现在是免费的，但是你必须遵循 Zend Optimizer 许可。这个产品可以对引擎产生的中间代码进行优化。
安装这个引擎比较简单，下载对应平台的版本以后，解开压缩文件，然后在 php.ini 文件里面加上下面两行，重新启动 Web 服务器，就搞定了。
zend_optimizer.optimization_level=15
zend_extension="/path/to/ZendOptimizer.so"
zend_loader.enable=Off
如果是 Win32 平台的话就应该是：
zend_optimizer.optimization_level=15
zend_extension_ts="C:path oendOptimizer.dll"
zend_loader.enable=Off
啊！没有搞错吧？怎么是三行？其实第三行是可选的。因为看起来把 zend_loader 关掉能提高一点速度，因此值得把这第三行放到 php.ini 。需要注意的是，关掉的前提条件是你没有在使用 Zend 加密程序。
二、缓冲
如果想要更进一步提升速度，我们就需要考虑采用缓冲技术了。有一些可选的解决方案，包括 Zend Cache (测试版本), APC, 以及 Afterburner Cache，另外还有 jpCache 等。
以上这些都是属于缓冲模块，他们把第一次对 .php 文件请求产生的中间代码存储在 Web 服务器的内存中，然后对以后的请求返回“编译好”的版本。因为这样减少了磁盘读写，而且都在内存工作，所以这个过程能显著提升应用性能，
现成的这类产品比较多，到底选择谁呢？
Zend Cache 是一款不错的商业产品，在第一次加载那些很大的 PHP 页面后，你会明显感受到速度的提升，服务器会留出更多的资源。可惜这个产品是要花银子的，但是在有些情形下，你可不要吝啬这些银子。
Afterburner Cache 是 Bware Technologies 的产品，目前还处于 Beta 版本，看起来似乎和 Zend Cashe 一样，但是它不能达到 Zend Cache 那样好的效果，也不能和 Zend 优化引擎一起工作，但是它是免费的，所以我采用了这个模块。
懂得HTML（超文本标识语言）的读者都应该知道在“＜FORM＞”的标签内可使用添加“GET”和“POST”参数的方式将资料送回HTTP服务器，其实，在PHP语言中我们同样可以使用“GET”及“POST”参数。除此之外，在网址上亦可以加上“GET”的资料，例如我们以下面的URL为例：
http://www.yourserver.com/download/down.php?id=1
http://www.yourserver.com/news/show.php?page=1
这些URL通常在网站的搜索引擎中会使用得最多，你看到的URL中都带了各种参数，目的是为了将资料传回http服务器以便找到相关信息。如果你觉得这个方式不好，笔者有另外一种方法可将传送的资料加在 URL 上，例如下面的网址：http://www.yourserver.com/vote/php/show.php/200107/2138/。
其对应的PHP源代码如下：
＜ PHP中有许多与文件系统有关的函数，这些函数不仅可以打开文件，还可以显示目录中的内容、移动文件和其他一些功能，许多人甚至用PHP开发基于互联网的文件资源管理器。
下面的脚本样例可以显示一个目录清单，注释已经包含在代码中：
＜? /