?
Ce document utilise Manuel du site Web PHP chinois Libérer
Preface[序]
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腳本從設(shè)計(jì)中獨(dú)立出來？這無疑地是在 PHP 郵件列表上所提問的最多的問題之一。雖然 PHP 被標(biāo)榜為 "HTML 嵌入式語言"， 在寫過許多php和html混合式的工程之后，我產(chǎn)生了一個(gè)分離表單和內(nèi)容的想法。而且，在許多公司里規(guī)劃設(shè)計(jì)者的角色和程序設(shè)計(jì)者是分開的。于是,這樣的一個(gè)模板解決方案產(chǎn)生了........
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.
例如在我們公司,一個(gè)應(yīng)用程序的開發(fā)流程如下：在提交計(jì)劃文檔之后,界面設(shè)計(jì)者[美工]制作了網(wǎng)站的外觀模型,然后把它交給后臺(tái)程序員。程序員使用PHP實(shí)現(xiàn)商業(yè)邏輯,同時(shí)使用外觀模型做成基本架構(gòu)。然后工程被返回到html頁面設(shè)計(jì)者繼續(xù)完善。就這樣工程可能在后臺(tái)程序員和頁面設(shè)計(jì)者之間來來回回好幾次。由于后臺(tái)程序員不喜歡干預(yù)任何有關(guān)html標(biāo)簽，同時(shí)也不需要美工們和php鬼混在一起；美工設(shè)計(jì)者只需要配置文件，動(dòng)態(tài)區(qū)塊和其他的界面部分，不必要去接觸那些錯(cuò)綜復(fù)雜的php代碼
。因此，這時(shí)候有一個(gè)很好的模板支持就顯得很重要了。
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.
縱觀現(xiàn)今存在的許多php模板解決方案,大多數(shù)都只是提供了用模板取代變量和將動(dòng)態(tài)區(qū)塊的功能有限的格式化的基本方法。但是我們的需求比這個(gè)要高的多。我們完全不想要php程序員去設(shè)計(jì)html頁面，可是這又是不可避免的。例如:如果美工想要在動(dòng)態(tài)區(qū)塊之間交替不同的背景顏色，他就可能得和程序員預(yù)先說好。同樣,美工們也應(yīng)該有自己對(duì)于頁面設(shè)計(jì)的配置文件，這同樣可以通過變量把他們拉到模板里邊去。繼續(xù)。
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年后期,我們就已經(jīng)開始為模板引擎寫說明文檔。在完成這個(gè)文檔之后,我們開始用c寫一個(gè)模板引擎，并有希望被包含到php里去。在 撞上了許多的技術(shù)難題的同時(shí)，“什么是模板應(yīng)該做的,什么不該做”這個(gè)問題，也被熱烈的討論著。從這些經(jīng)驗(yàn)，我們決定應(yīng)該用Php將模板引擎寫成一個(gè)類，讓任何覺得合適的人使用它。所以我們寫了一個(gè)引擎，從此就有了smarty.(注:這個(gè)類以前從來沒有公開發(fā)表過)。這個(gè)類幾乎達(dá)到了我們所有的要求：常規(guī)變量替換，支持包括其他模板，使用配置文件集成設(shè)置，嵌入Php代碼，限制'if'語句的作用，還有更多的可以多層嵌套的健壯的動(dòng)態(tài)區(qū)塊。它用常規(guī)表達(dá)式做到這一切，于是代碼變得相當(dāng)，我們可以說：令人費(fèi)解的。在每次調(diào)用的時(shí)候，都要去解析 那些語法和常規(guī)表達(dá)式，于是在大型應(yīng)用的時(shí)候，它顯然慢了下來。在程序員的眼光看來，最大的問題還是使用php腳本建立和處理模板和動(dòng)態(tài)區(qū)塊的所有必要工作。我們應(yīng)該如何使他變得更簡單？
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應(yīng)該有怎樣的最后表現(xiàn)。我們知道php代碼如果沒有了模板解析的開銷將有多快，我們也知道從一般的美工看來php語言是多么的"恐怖"，然而這一切可以被一種更簡單的模板語法掩飾掉。我們應(yīng)該怎樣把這兩種方法的長處結(jié)合起來？
于是，Smarty誕生了......