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 內嵌式腳本語言”後，當程式設計 師在混合使用 HTML 與 PHP 開發專案時會想到分離呈現與內容是一件好事 （Good Thing [TM]）。此外，許多公司裡面會將網頁開發人員分成網頁設計師與程式設計師等 不同的角色，因此我們可知必定需要使用樣版的觀念來解決問題。
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 設計人員 間多次的來回往返，因此有良好的樣板規劃是很重要的，因為程式設計人員不希望撰 寫 HTML 程式碼，且 HTML 設計人員也不希望他們的 HTML 碼被 PHP 程式碼包圍。 HTML 設計人員需要支援組態檔案、動態區塊（dynamic block），與其他的介面議題 ，但是他們不希望處理更為錯綜複雜的 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 可選擇的樣板系統，多數的樣板系統只有提供陽春的變數替 代方式與有限的動態區塊處理函式，但是我們所需要的是更強大的功能。我們不希望 程式設計人員分心去注意 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 的 類別方式撰寫，讓每個人可視自己的情況使用，所以我們依我們的需求寫了一個引擎 ，這就是 SmartTemplate 產生的原因。以下是我們想要的特性：固定的變數替換方式，支援在樣板內可包含其 他樣板，可整合組態檔（config file），可內嵌 PHP 程式碼，可支援有限數目的 'if' 陳述句與更可靠的動態區塊或巢狀式動態區塊。SmartTemplate 可以用正規表 示式完成以上功能，且程式碼產生的結果具不可通透性（impenetrable），而且當也 應用在大型應用程式中會因為剖析與正規語法的效能不佳使得整體效能相當不理想。 最大的問題在於，當以程式設計人員的角度出發時，在設定與處理樣版與動態區塊時 ，要如何事先做好應該準備好的先前工作呢？
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...
SmartTemplate 最後變成 Smarty，我們知道 PHP 程式碼之所以快是因為少了 變數樣式分析，我們也知道每位使用者對嚴謹與麻煩的認知是不一樣的，但是我們可 以使用樣板系統的語法解決。我們要如何擁有上述兩個優點呢？這也是 Smarty 誕生 的原因...