It is undoubtedly one of the most asked questions on the PHP mailing lists: how do I make my PHP scripts independent of the layout? While PHP is billed as "HTML embedded scripting language", after writing a couple of projects that mixed PHP and HTML freely one comes up with the idea that separation of form and content is a Good Thing [TM]. In addition, in many companies the roles of layout designer and programmer are separate. Consequently, the search for a templating solution ensues.

该如何使我的PHP脚本从设计中独立出来?这无疑地是在 PHP 邮件列表上所提问的最多的问题之一。虽然 PHP 被标榜为 "HTML 嵌入式语言", 在写过许多php和html混合式的工程之后,我产生了一个分离表单和内容的想法。而且,在许多公司里规划设计者的角色和程序设计者是分开的。于是,这样的一个模板解决方案产生了........

In our company for example, the development of an application goes on as follows: After the requirements docs are done, the interface designer makes mockups of the interface and gives them to the programmer. The programmer implements business logic in PHP and uses interface mockups to create skeleton templates. The project is then handed off to the HTML designer/web page layout person who brings the templates up to their full glory. The project may go back and forth between programming/HTML a couple of times. Thus, it's important to have good template support because programmers don't want anything to do with HTML and don't want HTML designers mucking around with PHP code. Designers need support for config files, dynamic blocks and other interface issues, but they don't want to have to deal with intricacies of the PHP programming language.

例如在我们公司,一个应用程序的开发流程如下:在提交计划文档之后,界面设计者[美工]制作了网站的外观模型,然后把它交给后台程序员。程序员使用PHP实现商业逻辑,同时使用外观模型做成基本架构。然后工程被返回到html页面设计者继续完善。就这样工程可能在后台程序员和页面设计者之间来来回回好几次。由于后台程序员不喜欢干预任何有关html标签,同时也不需要美工们和php鬼混在一起;美工设计者只需要配置文件,动态区块和其他的界面部分,不必要去接触那些错综复杂的php代码 。因此,这时候有一个很好的模板支持就显得很重要了。
Looking at many templating solutions available for PHP today, most of them provide a rudimentary way of substituting variables into templates and do a limited form of dynamic block functionality. But our needs required a bit more than that. We didn't want programmers to be dealing with HTML layout at ALL, but this was almost inevitable. For instance, if a designer wanted background colors to alternate on dynamic blocks, this had to be worked out with the programmer in advance. We also needed designers to be able to use their own configuration files, and pull variables from them into the templates. The list goes on.


We started out writing out a spec for a back in late 1999. After finishing the spec, we began to work on a written in C that would hopefully be accepted for inclusion with PHP. Not only did we run into many complicated technical barriers, but there was also much heated debate about exactly what a should and should not do. From this experience, we decided that the should be written in PHP as a class, for anyone to use as they see fit. So we wrote an engine that did just that and SmartTemplate came into existence (note: this class was never submitted to the public). It was a class that did almost everything we wanted: regular variable substitution, supported including other templates, integration with config files, embedding PHP code, limited 'if' statement functionality and much more robust dynamic blocks which could be multiply nested. It did all this with regular expressions and the code turned out to be rather, shall we say, impenetrable. It was also noticably slow in large applications from all the parsing and regular expression work it had to do on each invocation. The biggest problem from a programmer's point of view was all the necessary work in the PHP script to setup and process templates and dynamic blocks. How do we make this easier?

早在1999年后期,我们就已经开始为模板引擎写说明文档。在完成这个文档之后,我们开始用c写一个模板引擎,并有希望被包含到php里去。在 撞上了许多的技术难题的同时,“什么是模板应该做的,什么不该做”这个问题,也被热烈的讨论着。从这些经验,我们决定应该用Php将模板引擎写成一个类,让任何觉得合适的人使用它。所以我们写了一个引擎,从此就有了smarty.(注:这个类以前从来没有公开发表过)。这个类几乎达到了我们所有的要求:常规变量替换,支持包括其他模板,使用配置文件集成设置,嵌入Php代码,限制'if'语句的作用,还有更多的可以多层嵌套的健壮的动态区块。它用常规表达式做到这一切,于是代码变得相当,我们可以说:令人费解的。在每次调用的时候,都要去解析 那些语法和常规表达式,于是在大型应用的时候,它显然慢了下来。在程序员的眼光看来,最大的问题还是使用php脚本建立和处理模板和动态区块的所有必要工作。我们应该如何使他变得更简单?

Then came the vision of what ultimately became Smarty. We know how fast PHP code is without the overhead of template parsing. We also know how meticulous and overbearing the PHP language may look to the average designer, and this could be masked with a much simpler templating syntax. So what if we combined the two strengths? Thus, Smarty was born...