Smarty 学习手册.doc

PHP Smarty 学习手册
该如何使我的PHP脚本从设计中独立出来?这无疑地是在 PHP 邮件列表上所提问的最多的问题之一。虽然 PHP 被标榜为"HTML 嵌入式语言", 在写过许多php和html混合式的工程之后,我产生了一个分离表单和内容的想法。而且,在许多公司里规划设计者的角色和程序设计者是分开的。于是,这样的一个模板解决方案产生了........
例如在我们公司,一个应用程序的开发流程如下:在提交计划文档之后,界面设计者[美工]制作了网站的外观模型,然后把它交给后台程序员。程序员使用PHP实现商业逻辑,同时使用外观模型做成基本架构。然后工程被返回到html页面设计者继续完善。就这样工程可能在后台程序员和页面设计者之间来来回回好几次。由于后台程序员不喜欢干预任何有关html标签,同时也不需要美工们和php鬼混在一起;美工设计者只需要配置文件,动态区块和其他的界面部分,不必要去接触那些错综复杂的php代码。因此,这时候有一个很好的模板支持就显得很重要了。
纵观现今存在的许多php模板解决方案,大多数都只是提供了用模板取代变量和将动态区块的功能有限的格式化的基本方法。但是我们的需求比这个要高的多。我们完全不想要php程序员去设计html页面,可是这又是不可避免的。例如:如果美工想要在动态区块之间交替不同的背景颜色,他就可能得和程序员预先说好。同样,美工们也应该有自己对于页面设计的配置文件,这同样可以通过变量把他们拉到模板里边去。继续。
早在1999年后期,我们就已经开始为模板引擎写说明文档。在完成这个文档之后,我们开始用c写一个模板引擎,并有希望被包含到php里去。在撞上了许多的技术难题的同时,“什么是模板应该做的,什么不该做”这个问题,也被热烈的讨论着。从这些经验,我们决定应该用Php将模板引擎写成一个类,让任何觉得合适的人使用它。所以我们写了一个引擎,从此就有了smarty.(注:这个类以前从来没有公开发表过)。这个类几乎达到了我们所有的要求:常规变量替换,支持包括其他模板,使用配置文件集成设置,嵌入Php代码,限制'if'语句的作用,还有更多的可以多层嵌套的健壮的动态区块。它用常规表达式做到这一切,于是代码变得相当,我们可以说:令人费解的。在每次调用的时候,都要去解析那些语法和常规表达式,于是在大型应用的时候,它显然慢了下来。在程序员的眼光看来,最大的问题还是使用php脚本建立和处理模板和动态区块的所有必要工作。我们应该如何使他变得更简单?
我们可以想象smarty应该有怎样的最后表现。我们知道php代码如果没有了模板解析的开销将有多快,我们也知道从一般的美工看来php语言是多么的"恐怖",然而这一切可以被一种更简单的模板语法掩饰掉。我们应该怎样把这两种方法的长处结合起来?于是,Smarty诞生了......
第一章什么是Smaty?
Smarty是一个php模板引擎。更准确的说,它分开了逻辑程序和外在的内容,提供了一种易于管理的方法。可以描述为应用程序员和美工扮演了不同的角色,因为在大多数情况下,他们不可能是同一个人。例如,你正在创建一个用于浏览新闻的网页,新闻标题,标签栏,作者和内容等都是内容要素,他们并不包含应该怎样去呈现。在Smarty的程序里,这些被忽略了。模板设计者们编辑模板,组合使用html标签和模板标签去格式化这些要素的输出(html表格,背景色,字体大小,样式表,等等)。有一天程序员想要改变文章检索的方式(也就是程序逻辑的改变)。这个改变不影响模板设计者,内容仍将准确的输出到模板。同样的,哪天美工吃多了想要完全重做界面,也不会影响到程序逻辑。因此,程序员可以改变逻辑而不需要重新构建模板,模板设计者可以改变模板而不影响到逻辑。
现在简短的说一下什么是smarty不做的。smarty不尝试将逻辑完全和模板分开。如果逻辑程序严格的用于页面表现,那么它在模板里不会出现问题。有个建议:让应用程序逻辑远离模板, 页面表现逻辑远离应用程序逻辑。这将在以后使内容更容易管理,程序更容易升级。
Smarty的特点之一是"模板编译"。意思是Smarty读取模板文件然后用他们创建php脚本。这些脚本创建以后将被执行。因此并没有花费模板文件的语法解析,同时每个模板可以享受到诸如Zend加速器() 或者PHP加速器()。这样的php编译器高速缓存解决方案。
Smaty的一些特点:
非常非常的快!
用php分析器干这个苦差事是有效的
不需要多余的模板语法解析,仅仅是编译一次
仅对修改过的模板文件进行重新编译
可以编辑'自定义函数'和自定义'变量',因此这种模板语言完全可以扩展
可以自行设置模板定界符,所以你可以使用{}, {{}}, <!--{}-->, 等等
诸