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代码 .

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?

在 撞上了许多的技术难题的同时,"什么是模板应该做的,什么不该做"这个问题,也被热烈的讨论着.
常规变量替换, 支持包括其他模板,使用配置文件集成设置, 嵌入Php代码,限制'if'语句的作用,还有更多的可以多层嵌套的健壮的动态区块
在每次调用的时候,都要去解析 那些语法和常规表达式,于是在大型应用的时候,它显然慢了下来

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...