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.
纵观现今存在的许多php模板解决方案,大多数都只是提供了用模板取代变量和将动态区块的功能有限的格式化的基本方法。但是我们的需求比这个要高的多。我们完全不想要php程序员去设计html页面，可是这又是不可避免的。例如:如果美工想要在动态区块之间交替不同的背景颜色，他就可能得和程序员预先说好。同样,美工们也应该有自己对于页面设计的配置文件，这同样可以通过变量把他们拉到模板里边去。继续。
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...
我们可以想象smarty应该有怎样的最后表现。我们知道php代码如果没有了模板解析的开销将有多快，我们也知道从一般的美工看来php语言是多么的"恐怖"，然而这一切可以被一种更简单的模板语法掩饰掉。我们应该怎样把这两种方法的长处结合起来？
于是，Smarty诞生了......