PHP 模板引擎SMARTY 原理

時間 2019-11-12

標籤 php 模板引擎 smarty 原理欄目 PHP 简体版

原文原文鏈接

1、MVC須要模板

   MVC最先是在SmallTalk語言的開發過程當中總結出的一種設計模式，MVC分別表明了"模型"、"視圖"和"控制"，目的就是讓不一樣的開發角色在大中型項目中各司其職。在網絡應用程序的開發中，能夠用下圖來表示各概念之間的關係。
該圖展現了一個簡單的WEB應用程序，用戶在瀏覽器上看到信息是數據庫服務器上的內容，但在這以前通過了應用服務器加工。開發人員負責的就是創建數據結構、處理數據的邏輯以及表示數據的方法。
   96年CGI在中國開始流行的時候，早期的WEB程序員都是從HTML開始自學成材的，在PERL中print一行行的HTML並非一件難事，可是隨着網絡的一步步提速，頁面大小也從當初的2、三十K暴漲了十倍。寫CGI程序就產生了一個迫切的要求：分開PERL和HTML源碼。因而，社會進步體如今開發小組內部的分工上。因爲美工和程序員對互相的工做並非十分熟悉，在進行合做的過程當中須要用一種約定的"語言"進行交流。
   這種語言並非咱們的母語或者英語，術語叫作"模板"，邏輯和表示依靠它聯繫。它是結合了HTML和腳本語言特徵的一種表達方式。經過這種方式，表示層能夠按照用戶所但願的格式來顯示通過邏輯層處理過的數據。若是你有Windows平臺下MFC的開發經驗,那麼必定會很熟悉Document/Document Template/View的封裝，這就是一個很典型的MVC例子。對於Web應用來講，我的認爲J2EE中的EJB/servlets/JSP是最強大的，固然還有簡潔優美的Structs。另外一個頗有名的實現就是COM/DCOM+ASP，這個組合在我國是最多人使用的。
   經過幾種MVC實如今WEB應用程序裏的對比，能夠獲得一個關於模板的概念：一組插入了HTML的腳本或者說是插入了腳本HTML，經過這種插入的內容來表示變化的數據。下面給出一個模板文件的例子，這個模板通過處理後在瀏覽器裏顯示"Hello, world!"

<html>
<head>
    <title>$greetings</title>
</head>
<body>
    $greetings
<body>
</html>

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

2、爲何選SMARTY?

   對PHP來講，有不少模板引擎可供選擇，好比最先的PHPLIB template和後起之秀Fast template，通過數次升級，已經至關成熟穩定。若是你對目前手中的模板引擎很滿意，那麼......也請往下看，相信你做爲一個自由軟件愛好者或者追求效率和優雅的開發者，下面的SMARTY介紹多少會有點意思。
   除了我的偏好的影響，我一直傾向於使用官方標準的實現，好比APACHE的XML引擎Axis。好處就是能夠得到儘量好的兼容性(好比早期MFC對於Win3x的兼容性就比其它的應用程序框架好，固然如今各類版本都很完善了)。SMARTY發佈以前我一直使用的是   PEAR 中的Integrated Template eXtension。這個引擎和PHPLIB template、Fast template幾乎是兼容的，從模板的語法到對模板的處理同出一轍：都是將模板讀入內存而後調用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同樣有豐富的函數庫，從統計字數到自動縮進、文字環繞以及正則表達式均可以直接使用；若是以爲不夠，好比須要數據結果集分頁顯示的功能，SMARTY還有很強的擴展能力，能夠經過插件的形式進行擴充。
   事實勝於雄辯。我設計了一個測試程序，經過速度和開發難度這兩個因素對比了一下SMARTY和PHPLIB template，選PHPLIB template的緣由是在patrick的文章《在PHP世界中選擇最合適的模板》中有一個PHPLIB template對Fast template的競賽，結果PHPLIB template大獲全勝，這使得SMARTY有了一個很好的對手。在測試以前，先談一下在安裝過程當中須要注意的問題。

3、可能遇到的問題

在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 = "/}";

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

4、反襯和類比

先構思一下對測試的設計。主要的評比因素固然是速度了。爲了進行速度測試，採起了算術平均數的做法。在測試頁面中重複將頁面生成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發現該模板已經被編譯過了，因而最耗時的一步被跳過了，而對手還要循序漸進地進行查找和替換工做。這是編譯原理裏講到的很經典的"用空間換時間"例子。

5、結論

   結論就是若是你已經愛上SMARTY了，那麼還等什麼呢？固然並非說它就全能，就如同我用MVC模式來寫個人我的網站，非但沒有減小工做量，反而老是要爲不一樣層次間的耦合勞神。
   SMARTY不適合什麼呢？舉個手冊裏的經典例子：天氣預報網站。我還想到一個：股市大盤。在這種網站上用SMARTY會因爲常常的重編譯而效率偏低，仍是PHPLIB template更爲適合。
   本文並非爲了對比兩種引擎，而是爲了說明SMARTY的優點。使用它最有意義之處在於它是PHP新體系的一部份，做爲一支獨立的力量，除了.NET和JAVA ONE這兩大致系以外，大中型web開發還有別的選擇。這對於GNU項目來講，其意義無異於劉鄧大軍千里躍進大別山。