(PHP)模板引擎Smarty介紹

模板

引擎Smarty深入淺出介紹——php

來自

: cjjer 做了部分變動

用PHP實現MVC開發模式的邏輯層和展示層有多種模板引擎可供選擇，但是官方引擎SMARTY誕生後，選擇就有了變化。它的理念和實現都是相當前衛的。本文主要討論SMARTY之於其他模板引擎的不同特點，簡要介紹了該引擎的安裝及使用，並用一個小的測試案例對比了SMARTY和PHPLIBtemplate的速度和易用性。

一、MVC需要模板

MVC最早是在SmallTalk語言的開發過程中總結出的一種設計模式，MVC分別代表了模型、視圖和控制，目的就是讓不同的開發角色在大中型項目中各司其職。在網路應用程式的開發中，可以用來表示各概念之間的關係。

該圖展示了一個簡單的WEB應用程式，使用者在瀏覽器上看到資訊是資料庫伺服器上的內容，但在這之前經過了應用伺服器加工。開發人員負責的就是建立資料結構、處理資料的邏輯以及表示資料的方法。

96年CGI在中國開始流行的時候，早期的WEB程式員都是從HTML開始自學成材的，在PERL中PRint一行行的HTML並不是一件難事，但是隨著網路的一步步提速，頁面大小也從當初的二、三十K暴漲了十倍。寫CGI程式就產生了一個迫切的要求：分開PERL和HTML源碼。於是，社會進步體現在開發小組內部的分工上。由於美工和程式員對互相的工作並不是十分熟悉，在進行合作的過程中需要用一種約定的語言進行交流。

這種語言並不是我們的母語或者英語，術語叫做模板，邏輯和表示依靠它聯絡。它是結合了HTML和指令碼語言特徵的一種表達方式。通過這種方式，展示層可以按照使用者所希望的格式來顯示經過邏輯層處理過的資料。如果你有Windows平台下MFC的開發經驗,那麼一定會很熟悉Document/DocumentTemplate/View的封裝，這就是一個很典型的MVC例子。對於Web應用來說，個人認為J2EE中的EJB/servlets/jsp是最強大的，當然還有簡潔優美的Structs。另一個很有名的實現就是COM/DCOM+asp，這個組合在我國是最多人使用的。

通過幾種MVC實現在WEB應用程式裡的對比，可以得到一個關於模板的概念：一組插入了HTML的指令碼或者說是插入了指令碼HTML，通過這種插入的內容來表示變化的資料。下面給出一個模板檔案的例子，這個模板經過處理後在瀏覽器裡顯示Hello,world!

$greetings

這裡暫且省略處理方式，在後面做專門對比討論。

二、為什麼選SMARTY?

對PHP來說，有很多模板引擎可供選擇，比如最早的PHPLIBtemplate和後起之秀Fasttemplate，經過數次升級，已經相當成熟穩定。如果你對目前手中的模板引擎很滿意，那麼......也請往下看，相信你作為一個自由軟體愛好者或者追求效率和優雅的開發人員，下面的SMARTY介紹多少會有點意思。

除了個人偏好的影響，我一直傾向於使用官方標準的實現，比如APACHE的xml引擎Axis。好處就是可以獲得儘可能好的相容性(比如早期MFC對於Win3x的相容性就比其它的應用程式架構好，當然現在各種版本都很完善了)。SMARTY發布之前我一直使用的是PEAR中的Integrated Template eXtension。這個引擎和PHPLIBtemplate、Fasttemplate幾乎是相容的，從模板的文法到對模板的處理同出一轍：都是將模板讀入記憶體然後調用parse()函數，用資料對預置的標記進行替換。

下面看看SMARTY是怎麼做的。接到request後，先判斷是否第一次請求該url，如果是，將該url所需的模板檔案編譯成php指令碼，然後redirect；如果不是，就是說該url的模板已經被編譯過了，檢查不需要重編譯後可以馬上redirect，重編譯條件可以自己設定為固定時限，預設的是模板檔案被修改。

怎麼樣，看起來是不是有點眼熟？想起來了──這不就是JSP的原理嘛！的確，這種編譯用在PHP這樣的解釋性指令碼引擎上顯得匪夷所思，但是仔細想想，java不也是由JVM解釋執行的嗎？這就叫沒有做不到，只有想不到。

既然談到了JAVA，就再對PHP的未來發表一點看法。PHP官方網站上宣布了要在2003年年底發布PHP5.0版。這個版本擁有很多嶄新的特性：比如異常處理，命名空間，更加物件導向等等。可以說越來越向JAVA靠攏，SMARTY也是新特性之一，使得PHP更適用於大中型項目的開發。但是似乎離我當初選擇它的原因──靈巧易用──越來越遠了。但就一個軟體的生存周期來看，PHP正處在成長期，開發人員賦予它更多的功能，以期能勝任商業應用是利大於弊的。作為PHP的忠實使用者，肯定不希望PHP總是被人指責能力不足吧？

為什麼選擇SMARTY，僅僅因為它很像JSP？當然有更為充分的理由。首先，除了第一次編譯的成本比較高之外，只要不修改模板檔案，編譯好的cache指令碼就隨時可用，省去了大量的parse()時間；其次SMARTY像PHP一樣有豐富的函數庫，從統計字數到自動縮排、文字環繞以及Regex都可以直接使用；如果覺得不夠，比如需要資料結果集分頁顯示的功能，SMARTY還有很強的擴充能力，可以通過外掛程式的形式進行擴充。

事實勝於雄辯。我設計了一個測試程式，通過速度和開發難度這兩個因素對比了一下SMARTY和PHPLIBtemplate，選PHPLIBtemplate的原因是在patrick的文章《在PHP世界中選擇最合適的模板》中有一個PHPLIB template對Fasttemplate的競賽，結果PHPLIBtemplate大獲全勝，這使得SMARTY有了一個很好的對手。在測試之前，先談一下在安裝過程中需要注意的問題。

三、可能遇到的問題

在SMARTY的 官方網站上，有詳盡的使用者手冊，可以選擇線上HTML和PDF格式的版本。這裡就不再涉及手冊上已有的內容，只是把初次使用可能遇到的問題做個解釋。

第一個問題就很要命：提示說找不到所需檔案？並不是每一個人都按照SMARTY預設目錄結構來寫應用的。這裡需要手工指定，假設目錄結構如下：

就需要在index.php裡指定目錄結構：

$smart->template_dir = "smarty/templates/";
$smart->compile_dir = "smarty/templates_c/";
$smart->config_dir = "smarty/configs/";
$smart->cache_dir = "smarty/cache/";

第一個問題解決了，緊接著就是第二個：我剛用Dreamweaver產生的漂亮模板怎麼不能用？並不是模板檔案有什麼問題，而是因為SMARTY預設的標記分隔字元是{}，不巧的是Javascript肯定包含這個標記。好在我們可以用任一字元當作分隔字元，再加上這兩句：

$smart->left_delimiter = "{/";
$smart->right_delimiter = "/}";

這下安裝就基本完成，沒問題了。

四、反襯和類比

先構思一下對測試的設計。主要的評比因素當然是速度了。為了進行速度測試，採取了算術平均數的作法。在測試頁面中重複將頁面產生N遍，再對比總頁面產生時間。另一個重要因素是易用性(至於擴充性不用比較已經有結果了)，所以使用的模板不能太小。我用的是我個人首頁的的頁面，一個用Firework+Dreamweaver產生的HTML檔案，大小約7K。其中的變數設定也採取最常用的區塊，在PHPLIB template裡叫block,而SMARTY則稱section。別小看這稱呼的不同，易用性標準分兩塊：模板檔案和指令檔的文法是否簡明易用。

下面就深入到測試中來。先看看兩種模板檔案的文法：藍條左邊是PHPLIB template的模板，右邊屬於SMARTY。個人偏好是不一樣的，所以這裡不作評論。著重對比一下指令碼裡的處理語句，先看PHPLIB template的：

$tpl->set_file('phplib', 'bigfile.htm');
$tpl->set_block('phplib', 'row', 'rows');
for ($j = 0; $j < 10; $j++){
$tpl->set_var('tag' ,"$j");
$tpl->parse('rows', 'row', true);
}
$tpl->parse('out', 'phplib');
$tpl->p('out');

下面是SMARTY的：

$smart->assign('row',$row);
$smart->display('bigfile.htm');

SMARTY只用了tags和row兩個變數，而PHPLIB template則多了模板檔案的handler，還有一個莫名其妙的out。說實在的這個out我當初學的時候就不知道為什麼要存在，現在看起來，還是彆扭。為什麼SMARTY少那麼多處理語句呢？答案是工作由引擎完成了。如果你喜歡鑽研來源程式，可以發現在Smarty_compiler.class.php裡有一個名叫_compile_tag()的函數，由它負責把section這個標籤轉換成php語句。這不是一個普通的標籤，它帶有參數和資料，節省了指令碼編程的工作量，而模板標籤上的工作量相差又不大，可以判定在易用性上SMARTY高出一疇。

下面該輪到我們最關注的速度了，畢竟對於一個熟練的web開發人員來說，掌握再困難的工具不過是時間問題，何況模板引擎這種學習曲線平緩的技術。而速度則是web應用程式的生命，尤其是模板引擎使用在並發訪問量很大的網站上，這點就更重要了。測試開始前，我覺得PHPLIB template會在這一環節上勝出，因為它經曆了很多次升級，已經基本沒有什麼bug,而且SMARTY的引擎個頭太大，不像它的對手只有兩個檔案。

果然，測試結果如，PHPLIB template有25%的速度優勢：

但不會一直這樣，我又按了一次重新整理，這次得到了不一樣的結果：

PHPLIB基本沒變化，但是SMARTY提高了25%的速度。繼續重新整理，得到的都是類似於第二次的結果：SMARTY比PHPLIB template 快上近10%。我想這就是編譯型比解釋型快的原理了。SMARTY引擎本身就很大，加上還要把模板編譯成php檔案，速度當然比不上小巧的PHPLIB template。但這隻是第一次的情況。第二次接到請求的時候，SMARTY發現該模板已經被編譯過了，於是最耗時的一步被跳過了，而對手還要按部就班地進行尋找和替換工作。這是編譯原理裡講到的很經典的"用空間換時間"例子。

五、結論

結論就是如果你已經愛上SMARTY了，那麼還等什麼呢？當然並不是說它就全能，就如同我用MVC模式來寫我的個人網站，非但沒有減少工作量，反而總是要為不同層次間的耦合勞神。

SMARTY不適合什麼呢？舉個手冊裡的經典例子：天氣預報網站。我還想到一個：股市大盤。在這種網站上用SMARTY會由於經常的重編譯而效率偏低，還是PHPLIB template更為適合。

本文並不是為了對比兩種引擎，而是為了說明SMARTY的優勢。使用它最有意義之處在於它是PHP新體系的一部份，作為一支獨立的力量，除了.NET和JAVA ONE這兩大體系之外，大中型web開發還有別的選擇。這對於GNU項目來說，其意義無異於劉鄧大軍千裡躍進大別山。

作者：於博翔

