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.
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 template engine back in late 1999. After finishing the spec, we began to work on a template engine 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 template engine should and should not do. From this experience, we decided that the template engine 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...