明輝手游網(wǎng)中心：是一個免費提供流行視頻軟件教程、在線學習分享的學習平臺！

PHP模板引擎SMARTY

發(fā)表時間：2024-02-02 來源：明輝站整理相關軟件相關文章人氣：

[摘要]用PHP實現(xiàn)MVC開發(fā)模式的邏輯層和表示層有多種模板引擎可供選擇， 但是官方引擎SMARTY誕生后，選擇就有了變化。它的理念和實現(xiàn)都是 相當"前衛(wèi)"的。本文主要討論SMARTY之于其他模板引擎的不同特點， 簡要介紹了該引擎的安裝及使用，并用一個小的測試案例對比了 SMARTY和...

用PHP實現(xiàn)MVC開發(fā)模式的邏輯層和表示層有多種模板引擎可供選擇， 但是官方引擎SMARTY誕生后，選擇就有了變化。它的理念和實現(xiàn)都是 相當"前衛(wèi)"的。本文主要討論SMARTY之于其他模板引擎的不同特點， 簡要介紹了該引擎的安裝及使用，并用一個小的測試案例對比了 SMARTY和PHPLIB template的速度和易用性。

一、MVC需要模板
MVC最早是在SmallTalk語言的開發(fā)過程中總結出的一種設計模式，MVC分別代 表了"模型"、"視圖"和"控制"，目的就是讓不同的開發(fā)角色在大中型項目中各司 其職。在網(wǎng)絡應用程序的開發(fā)中，可以用下圖來表示各概念之間的關系。


該圖展示了一個簡單的WEB應用程序，用戶在瀏覽器上看到信息是數(shù)據(jù)庫服務 器上的內(nèi)容，但在這之前經(jīng)過了應用服務器加工。開發(fā)人員負責的就是建立數(shù) 據(jù)結構、處理數(shù)據(jù)的邏輯以及表示數(shù)據(jù)的方法。

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

這種語言并不是我們的母語或者英語，術語叫做"模板"，邏輯和表示依靠它聯(lián) 系。它是結合了HTML和腳本語言特征的一種表達方式。通過這種方式，表示層 可以按照用戶所希望的格式來顯示經(jīng)過邏輯層處理過的數(shù)據(jù)。如果你有 Windows平臺下MFC的開發(fā)經(jīng)驗,那么一定會很熟悉Document/Document Template/View的封裝，這就是一個很典型的MVC例子。對于Web應用來說，個 人認為J2EE中的EJB/servlets/JSP是最強大的，當然還有簡潔優(yōu)美的Structs。 另一個很有名的實現(xiàn)就是COM/DCOM+ASP，這個組合在我國是最多人使用 的。

通過幾種MVC實現(xiàn)在WEB應用程序里的對比，可以得到一個關于模板的概念： 一組插入了HTML的腳本或者說是插入了腳本HTML，通過這種插入的內(nèi)容來表 示變化的數(shù)據(jù)。下面給出一個模板文件的例子，這個模板經(jīng)過處理后在瀏覽器 里顯示"Hello, world!"

引言：
--------------------------------------------------------------------------------


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


--------------------------------------------------------------------------------



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

二、為什么選SMARTY?
對PHP來說，有很多模板引擎可供選擇，比如最早的PHPLIB template和后起之 秀Fast template，經(jīng)過數(shù)次升級，已經(jīng)相當成熟穩(wěn)定。如果你對目前手中的模 板引擎很滿意，那么......也請往下看，相信你作為一個自由軟件愛好者或者追求 效率和優(yōu)雅的開發(fā)者，下面的SMARTY介紹多少會有點意思。

除了個人偏好的影響，我一直傾向于使用官方標準的實現(xiàn)，比如APACHE的XML 引擎Axis。好處就是可以獲得盡可能好的兼容性(比如早期MFC對于Win3x的兼 容性就比其它的應用程序框架好，當然現(xiàn)在各種版本都很完善了)。SMARTY發(fā) 布之前我一直使用的是PEAR 中的Integrated Template eXtension。這個引擎和 PHPLIB template、Fast template幾乎是兼容的，從模板的語法到對模板的處理 同出一轍：都是將模板讀入內(nèi)存然后調(diào)用parse()函數(shù)，用數(shù)據(jù)對預置的標記進 行替換。

下面看看SMARTY是怎么做的。接到request后，先判斷是否第一次請求該url， 如果是，將該url所需的模板文件"編譯"成php腳本，然后redirect；如果不是， 就是說該url的模板已經(jīng)被"編譯"過了，檢查不需要重編譯后可以馬上redirect， 重編譯條件可以自己設定為固定時限，默認的是模板文件被修改。

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

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

為什么選擇SMARTY，僅僅因為它很像JSP？當然有更為充分的理由。首先，除 了第一次編譯的成本比較高之外，只要不修改模板文件，編譯好的cache腳本就 隨時可用，省去了大量的parse()時間；其次SMARTY像PHP一樣有豐富的函數(shù) 庫，從統(tǒng)計字數(shù)到自動縮進、文字環(huán)繞以及正則表達式都可以直接使用；如果 覺得不夠，比如需要數(shù)據(jù)結果集分頁顯示的功能，SMARTY還有很強的擴展能 力，可以通過插件的形式進行擴充。

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

三、可能遇到的問題
在SMARTY的官方網(wǎng)站上，有詳盡的用戶手冊，可以選擇在線HTML和PDF格式 的版本。這里就不再涉及手冊上已有的內(nèi)容，只是把初次使用可能遇到的問題 做個解釋。

第一個問題就很要命：提示說找不到所需文件？并不是每一個人都按照 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 = "/}";


--------------------------------------------------------------------------------



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

四、反襯和類比
先構思一下對測試的設計。主要的評比因素當然是速度了。為了進行速度測 試，采取了算術平均數(shù)的作法。在測試頁面中重復將頁面生成N遍，再對比總頁 面生成時間。另一個重要因素是易用性(至于擴展性不用比較已經(jīng)有結果了)，所 以使用的模板不能太小。我用的是我個人主頁的的頁面，一個用 Firework+Dreamweaver生成的HTML文件，大小約7K。其中的變量設置也采取 最常用的區(qū)塊，在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我當初學的時候就不知道 為什么要存在，現(xiàn)在看起來，還是別扭。為什么SMARTY少那么多處理語句 呢？答案是工作由引擎完成了。如果你喜歡鉆研源程序，可以發(fā)現(xiàn)在 Smarty_compiler.class.php里有一個名叫_compile_tag()的函數(shù)，由它負責把 section這個標簽轉換成php語句。這不是一個普通的標簽，它帶有參數(shù)和數(shù) 據(jù)，節(jié)省了腳本編程的工作量，而模板標簽上的工作量相差又不大，可以判定 在易用性上SMARTY高出一疇。

下面該輪到我們最關注的速度了，畢竟對于一個熟練的web開發(fā)者來說，掌握再 困難的工具不過是時間問題，何況模板引擎這種學習曲線平緩的技術。而速度 則是web應用程序的生命，尤其是模板引擎使用在并發(fā)訪問量很大的站點上，這 點就更重要了。測試開始前，我覺得PHPLIB template會在這一環(huán)節(jié)上勝出，因 為它經(jīng)歷了很多次升級，已經(jīng)基本沒有什么bug,而且SMARTY的引擎?zhèn)�頭太 大，不像它的對手只有兩個文件。

果然，測試結果如下圖，PHPLIB template有25%的速度優(yōu)勢：


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


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

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

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

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

參考文獻

SMARTY官方站點：smarty.php.net
王晨：《在PHP世界中選擇最合適的模板》
本文中測試程序下載：test.tar.bz2
http://phpe.net/uploads/attach/article_1058233528.bz2
About the author
于博翔，筆名于萊來自對外經(jīng)濟貿(mào)易大學信息學院。GNU癡迷者，喜歡練習各種編程語 言，研究各種體系框架。

發(fā)帖數(shù)：1275 回復：與許多的PHP script 都將使用Smarty為核心引擎,而Smarty到底是甚麼? 2003-08-10 14:07

在PHP世界中選擇最合適的模板--比較PHPLIB Template和FastTemplate



PHP工程中的模板應用，是進行中型乃至大型項目中建議采用的處理表現(xiàn)層的好辦法。但 是具體到模板的實施，采用何種現(xiàn)有的模板技術卻需要進行一番比較。

PHP世界中比較受關注的模板處理有PHPLIB Template和FastTemplate兩種，我們對技術的易用性和速 度進行了評測--想知道結果嗎？

事情的起因：你用過FastTemplate嗎？
對于PHP工程中的模板應用，其實我和我的同事們已經(jīng)在許多的項目中接觸過--關于它的好處，我想無論 是在實際開發(fā)階段還是上升到設計模式的角度都已經(jīng)有很多"前輩先哲"討論過了。就項目實施而言，在一 些中型甚至大型的項目中，有效的將HTML（還有其他文本形式的表現(xiàn)層）和PHP代碼分開，不僅在開發(fā) 階段可以分別提高界面設計人員和應用程序編寫人員的工作效率，更會給項目的測試和維護帶來巨大的便 利。

但是--本文的目的不是討論模板的優(yōu)缺點，也不是作為指導性的教程講授如何在PHP項目中使用模板，而 是以應用的視角比較兩種PHP世界中最為流行的模板處理方式（其實只不過是兩種模板類）：PHPLIB Template和FastTemplate。

其實我一直都在"安靜"的使用著PHPLIB Template--很穩(wěn)定而且看上去速度也不錯，以至于我并不想再去 不安的尋找可能更好的替代品--雖然我也知道這個地球上還有FastTemplate這樣的東西（而且還在Perl的 世界中大名鼎鼎）。直到有一天，有一個同事問我："不知道FastTemplate怎么樣？為什么我們不試試 FastTemplate呢？"

"好吧，就讓我們試試！"不過作為一個穩(wěn)妥的方法，在任何新的模式或者方法引入項目之前，最好能夠更 加全面的了解它，以及找到一個或者幾個足夠說服自己和同事去采用它的理由--對于FastTemplate也不例 外。

主角出場：了解PHPLIB Template以及FastTemplate
前面已經(jīng)說過，我已經(jīng)使用PHPLIB有一段時間了--我想屏幕前的你也許和我一樣，也對這個優(yōu)秀的工具類 庫印象很深吧！同樣，當我開始尋求模板的解決辦法時，很自然的就會在最接近身邊的工具箱里搜尋，于 是我找到了PHPLIB中的Template類。在最初的很快瀏覽完它提供的API之后（當然還得感謝PHPLIB詳盡 的文檔），我就開始了使用它的歷程--直到現(xiàn)在。

而FastTemplate似乎名氣更響亮一些，在其發(fā)跡的Perl世界中自然是這樣，在PHP世界中似乎也是，單單 從這一點上就足夠讓人相信它的能力了。

關于兩者的使用辦法，本來我想在這里多廢話幾句的；但是畢竟覺得自己恐怕專門寫出兩篇教程來也沒有 現(xiàn)有的教程受歡迎--在本文的參考資料中有關于PHPLIB Template和FastTemplate的有名教程，如果你自 認還沒有對這兩種模板或者其中的一種有所認識，建議你先去看看那兩篇文章，應該會得到不少有益的模 板應用知識。

（一番鼠標點擊以及眼球轉動甚至親自編寫測試代碼之后，）現(xiàn)在你對兩種模板都有了一些了解，也許已 經(jīng)發(fā)現(xiàn)了它們之間的很多相似之處，在下面我就會將這些地方歸納一下。

變量的設置
很明顯，{FOO}或者{BAR}的形式在兩種模板中都是指定的形式；也就是說，兩種模板處理方式 中，模板文件本身的外貌應該可以是一致的（比如都是HTML文件中間含有將要被替換的以{}標識 的變量）。
模板類的初始化（類的構建器）
都需要在構建模板類的時候指定模板文件存在的目錄位置。
變量的替換
模板處理中最常用的就是變量替換，兩種方式除了方法名不同之外（PHPLIB Template采用 set_var()，而FastTemplate采用assign()），用法幾乎也是一致的--可以采用(key, value)的方式， 也可以直接傳遞一個數(shù)組(array(key=>value))。
模板文件的處理
都是采用為每一個模板文件指定一個句柄（handler）的辦法，同時句柄也可以作為變量的值替換 另一模板文件中的變量。
解析、輸出過程
都是需要調(diào)用parse()方法（這個方法名竟然是相同的）將需要輸出的模板文件解析后賦值給一個 句柄，然后調(diào)用各自輸出的方法（PHPLIB Template中是p()，F(xiàn)astTemplate中是FastPrint()）輸 出該句柄的內(nèi)容并結束處理。
重復解析的過程
比如從數(shù)據(jù)庫中取出幾條記錄需要顯示而模板文件只有可替換的一行變量的時候，就很需要這樣的 功能。兩者都具有這樣的功能，只是使用時稍稍有些不同而已（PHPLIB Template采用 parse(handler, value, true)，而FastTemplate采用parse(handler, .value)在值的前面多加一個 點），應該說PHPLIB Template的方法構造得相對優(yōu)美一點。
區(qū)塊解析的過程（或者可以稱作動態(tài)解析）
想像一下你需要從數(shù)據(jù)庫中取出符合條件的數(shù)據(jù)并顯示在網(wǎng)頁中--但是因為條件會不盡相同，你并 不能明確的知道會有多少條數(shù)據(jù)--這時候如果你又要采用模板，那么區(qū)塊就是最好的選擇。它是在 模板中用特定的符號定義的部分，這一部分可以反復的被解析并添加到（而不是前一次的解析被后 一次覆蓋）輸出網(wǎng)頁中。區(qū)塊也許就像下面顯示的一樣（左邊是PHPLIB Template采用的區(qū)塊設 置，而右邊則是FastTemplate采用的）：



好吧，如果你對以上蒼白的文字介紹還是有些摸不著頭腦，那么我們就來看看兩個詳盡的模板處理的例程 吧�。ㄈ绻阌信d趣對后面的測試代碼進行發(fā)掘，就會發(fā)現(xiàn)其實以下的兩個例子都來自那里）


怎么樣，是不是感覺幾乎是一致的？下面是區(qū)塊解析的例子，你也會發(fā)現(xiàn)同樣的效果：


我們的測試目標和結果
結束了對PHPLIB Template和FastTemplate的了解，應該可以進入本文的正題了--在應用環(huán)境中當然應該 選擇易于使用同時速度理想的部件構建系統(tǒng)，那么對于這樣的兩種類似技術，進行評測非常有必要。評測 應該是由兩部分組成：技術的使用難度和速度的快慢程度--前者是評論的部分，而后者是測試的部分。對 于前者，我們主要針對兩個類提供的API進行評論；對于后者，我們會讓測試的數(shù)據(jù)來說話，當然這中間 免不了需要編寫一些簡單的測試代碼。

回合一：技術的易用性
這一回合主要是探討PHPLIB Template和FastTemplate提供的API的使用情況。應該說，前者提供的API 更符合PHP的一些常見編碼慣例（特別是當你的項目中采用了PHPLIB的其他類時，這樣的規(guī)范性會對整 個項目有好的影響）；而后者的一些方法名總覺得有些別扭（希望你不要覺得這只是我的狹隘看法，比如 FastPrint()等等），同時方法的參數(shù)也不是非常"地道"，這一點你也可以從剛才的代碼看出來。

另外一點需要指出的是，對于模板區(qū)塊的解析，F(xiàn)astTemplate直到最近的版本才開始支持。也就是說，如 果你采用了之前的版本，在處理諸如數(shù)據(jù)庫中記錄的輸出等內(nèi)容時，不得不把這塊內(nèi)容獨立存儲在某處， 然后在模板分析處理時附加上這個文件--真是一件讓人難受的事情，尤其是對網(wǎng)頁設計人員而言。

當然還有一點需要考察--那就是對于PHP版本的支持。PHPLIB產(chǎn)生在PHP3的時代，這一點和 FastTemplate差不多；但是根據(jù)我們的應用，PHPLIB在現(xiàn)在的PHP4環(huán)境下運行相當好，而 FastTemplate的網(wǎng)頁上則顯示了一些信息表明對于PHP4也許它還有一些BUG存在。

好了，講了這么多（也許你會覺得都是FastTemplate的壞話），這個回合的勝利者很明顯：PHPLIB Template，尤其是你同時在使用PHPLIB的其他類時，這樣的技術易用性更加明顯（你將不會對這些出自 同一個開發(fā)小組的API感到陌生）。

回合二：處理速度
也許這才是很多人最關注的部分--在這個回合中，我們會采用兩種模板處理的方式：一種是常規(guī)的分析、 替換，另一種是對區(qū)塊的解析、替換--同時這樣的兩種方式也是在實際系統(tǒng)中應用最多的：前者是一般的 頁面處理，后者是關于數(shù)據(jù)庫內(nèi)容的輸出處理。同時，由于兩種模板類采用的模板文件的格式基本相同， 使得我們可以提供幾乎一致的模板文件分別供兩種模板解析，更增加了測試的可信度。

開展這樣的速度測試之前會擬定一個測試方案，簡單說來就是對于兩種處理方式分別編寫兩個PHP測試頁 面，同時有一個控制測試的頁面多次調(diào)用這兩個頁面并記錄時間供采集測試數(shù)據(jù)。（如果有興趣你還可以 參考以下詳細的測試方案，也許會對你深入了解這次測試有所幫助）

小結--在整個測試系統(tǒng)完成之后，我們應該能夠得到/test目錄中如下的文件清單：

（有點復雜的測試方案）

首先是確定測試的硬件和軟件環(huán)境--硬件肯定是自己的機器了，Intel Celeron 733MHz， 256M RAM，40G HDD；軟件平臺中OS為Win2K Pro，Web服務器為Apache+PHP，且以 模塊方式運行。

其次是規(guī)劃這次測試的系統(tǒng)--當然先在Web服務器的文檔根目錄下開一個tpl_test的新目錄用 以放置這個測試的所有文件；然后在/tpl_test下建立include目錄以存放兩個模板類文件（我 們測試的核心，以.inc.php為文件擴展名）以及一個測試類文件（包括了計時和記錄日志以 及讀取日志并分析等功能，以.inc.php為文件擴展名）和一個數(shù)據(jù)文件（為區(qū)塊解析的測試 做準備，主要包含了一個二維數(shù)組，同樣以.inc.php為文件擴展名），建立ihtml目錄存放使 用的模板文件（需要被解析的模板文件，以.ihtml為文件擴展名），建立logs目錄存放測試產(chǎn) 生的日志（后面就是發(fā)現(xiàn)，其實測試的數(shù)據(jù)就是由對這些日志的分析得到的，以.log為文件 擴展名）。當然，兩種模板的處理PHP文件就放在/test目錄下。這次測試最關鍵的一點是， 還需要建立一個PHP文件，對以上提到的負責模板處理的文件進行數(shù)次調(diào)用：比如一個文件 fast_test.php是采用FastTemplate解析模板的，而phplib_test.php是采用PHPLIB Template 解析的，那么這個得出結果的PHP文件就負責多次以HTTP的方式請求以上的兩個頁面以獲 得測試數(shù)據(jù)。

選擇待解析的模板和PHP程序編寫--因為兩種模板處理方式對于模板文件本身的格式要求幾 乎一致（比如待替換變量都采用{VAR}的形式等等），因此可以盡量保證同一測試中兩者選 用的模板盡可能相同以謀求測試的最大公正性；同時在前文提到，為模擬現(xiàn)實系統(tǒng)中常用的 兩種模板應用：一般的頁面處理和對數(shù)據(jù)庫內(nèi)容的輸出處理，測試使用的模板文件也分成兩 種：一種是普通的帶有一些待替換變量的模板文件，另一種是帶有區(qū)塊的需要根據(jù)應輸出的 內(nèi)容反復替換的模板文件。同樣對于這兩種模板文件，也需要分別編寫兩種不同的PHP文件 進行解析。

測試方法--在瀏覽器中向/test/result.php提出請求，需要帶參數(shù)type=[simple complex]，在 返回的結果中即可看到兩種模板在簡單或者復雜模式下的測試結果。

Level 1
Level 2
Level 3
Remark

/test


測試系統(tǒng)的根目錄







result.php

進行測試并產(chǎn)生結果的PHP文件，測 試時只需要在瀏覽器中請求該頁面即 可獲得測試信息


simple__test_phplib.php

使用PHPLIB Template對一般模板進 行分析的PHP文件


simple__test_fast.php

使用FastTemplate對一般模板進行分 析的PHP文件


complex__test_phplib.php

使用PHPLIB Template對帶區(qū)塊模板 進行分析的PHP文件


complex__test_fast.php

使用FastTemplate對帶區(qū)塊模板進行 分析的PHP文件







/include

包含PHP類文件.inc.php



phplibTemplate.inc.php
PHPLIB Template類文件



FastTemplate.inc.php
FastTemplate類文件



TplTest.inc.php
測試中需要使用的測試類，包含諸如 計時、讀取/分析日志等方法。



data.inc.php
測試帶區(qū)塊模板時采用的數(shù)據(jù)文件。







/ihtml

包含模板文件.ihtml



simple_phplib.ihtml
采用PHPLIB Template處理的一般模 板文件



simple_fast.ihtml
采用FastTemplate處理的一般模板文 件



complex_phplib.ihtml
采用PHPLIB Template處理的帶區(qū)塊 的模板文件



complex_fast.ihtml
采用FastTemplate處理的帶區(qū)塊的模 板文件







/logs

包含日志文件.log



simple_phplib.log
采用PHPLIB Template處理一般模板 生成的日志



simple_fast.log
采用FastTemplate處理一般模板生成 的日志



complex_phplib.log
采用PHPLIB Template處理帶區(qū)塊模 板生成的日志



complex_fast.log
采用FastTemplate處理帶區(qū)塊模板生 成的日志

經(jīng)過了測試系統(tǒng)的設計和編寫，并且向負責網(wǎng)頁設計的同事討來兩個模板之后，我們就可以訪問這個系統(tǒng) 了--前期的辛勤勞動使得現(xiàn)在觀看結果的工作只需要在瀏覽器的地址欄中打入 http://localhost/tpl_test/ result.php?type=[simple complex] （如果你是在其他的非本地服務器中進行這個測試，那么域名應采用 所在服務器的域名--比如我自己的機器叫做patrick等等）。下面是我自己在某一次的測試中獲得的結 果：（測試結果數(shù)據(jù)解釋）

名稱
解釋
備注

amount
測試總數(shù)（連續(xù)請求該頁面總數(shù)）
該參數(shù)可在result.php文件中修改

max_seq
最大處理時間的序號
范圍在1－amount之間

max_value
最大處理時間的值
峰值數(shù)據(jù)供參考

min_seq
最小處理時間的序號
范圍在1－amount之間

min_value
最小處理時間的值
峰值數(shù)據(jù)供參考

average
平均處理時間
測試中最有價值的數(shù)據(jù)


當然，如果你覺得一次測試的結果并不可靠，可以反復按下瀏覽器的刷新按鈕，就能夠觀察到不同測試的

結果（理論上應該是相差無幾）。

測試結果以及頒發(fā)"XX選擇獎"
好了，在偏重速度測試的回合二中PHPLIB Template以驚人的2倍的速度戰(zhàn)勝了FastTemplate；而同時在 第一回合中PHPLIB Template有以良好的API設計和易用性占得上風。結果顯而易見--我們的選擇獎當然頒 發(fā)給了PHPLIB Template，同時這次的測試也讓我們對PHPLIB這個類庫設計有了更深的了解。

主觀評價
既然有了結果，那么FastTemplate自然也就不能進入我們的項目了--雖然從結果上看來我們花費了半天的 時間得到了一個毫無變化的結果（PHPLIB Template繼續(xù)很好的在項目中使用），但是測試的過程卻是很 有價值的，特別是采用PHP進行測試的方法，應該會在以后的類似決策中起到一定參考作用。