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