（本文發于java emag第一期）
一、起源與現狀：

關于template和jsp的起源還要追述到的遠古年代，那個時候的人們用cgi來開發web應用，在一個cgi程序中寫html標簽。

在這之后世界開始朝不同的方向發展：sun公司提供了類似于cgi的servlet解決方案，但是無論是cgi還是servlet都面對同一個問題：在程序里寫html標簽，無論如何都不是一個明智的解決方案。于是sun公司于1999年推出了jsp技術。而在另一個世界里，以php和asp為代表的scriptlet頁面腳本技術開始廣泛應用。

不過即便如此，問題并沒有結束，新的問題出現了：業務和html標簽的混合，這個問題不僅導致頁面結構的混亂，同時也使代碼本身難以維護。

于是來自起源于70年代后期的mvc模式被引入開發。mvc的三個角色：model——包含除ui的數據和行為的所有數據和行為。view是表示ui中模型的顯示。任何信息的變化都由mvc中的第三個成員來處理——控制器。

在之后的應用中，出現了技術的第一次飛躍：前端的顯示邏輯和后端的業務邏輯分離，com組件或ejb或corba用于處理業務邏輯，asp、jsp以及php被用于前端的顯示。這個就是的model 1階段（頁面控制器模式）。

不過這個開發模式有很多問題：

1.       頁面中必須寫入scriptlet調用組件以獲得所必需的數據。

2.       處理顯示邏輯上scriptlet代碼和html代碼混合交錯。

3.       調試困難。jsp被編譯成servlet，頁面上的調試信息不足以定位錯誤。

這一切都是因為在model 1中并沒有分離視圖和控制器。完全分離視圖和控制器就成了必須。這就是model 2。它把model 1中未解決的問題——分離對組件（業務邏輯）的調用工作，把這部分工作移植到了控制器?，F在似乎完美了，不過等等，原來的控制器從頁面中分離后，頁面所需的數據怎么獲得，誰來處理頁面顯示邏輯？兩個辦法：1. 繼續利用asp，php或者jsp等機制，不過由于它們是運行在web環境下的，他們所要顯示的數據（后端邏輯產生的結果）就需要通過控制器放入request流中；2. 使用新手法——模板技術，使用獨立的模板技術由于脫離的了web環境，會給開發測試帶來相當的便利。至于頁面所需數據傳入一個pojo就行而不是request對象。

模板技術最先開始于php的世界，出現了phplib template和fasttemplate這兩位英雄。不久模板技術就被引入到java 世界里。目前比較流行的模板技術有：xstl，velocity，jdynamite，tapestry等。另外因為jsp技術畢竟是目前標準，相當的系統還是利用jsp來完成頁面顯示邏輯部分，在sun公司的jstl外，各個第三方組織也紛紛推出了自己的taglib，一個代表是struts tablib。

二、 模板技術分析：

模板技術從本質上來講，它是一個占位符動態替換技術。一個完整的模板技術需要四個元素：0. 模板語言，1. 包含模板語言的模板文件，2. 擁有動態數據的數據對象，3. 模板引擎。以下就具體討論這四個元素。（在討論過程中，我只列舉了幾個不同特點技術，其它技術或有雷同就不重復了）

1.       模板語言：

模板語言包括：變量標識和表達式語句。根據表達式的控制力不同，可以分為強控制力模板語言和弱控制力模板語言。而根據模板語言與html的兼容性不同，又可以分為兼容性模板語言和非兼容性模板語言。

模板語言要處理三個要點：

1. 標量標記。把變量標識插入html的方法很多。其中一種是使用類似html的標簽；另一種是使用特殊標識，如velocity或者jdynamite；第三種是擴展html標簽，如tapestry。采用何種方式有著很多考慮，一個比較常見的考慮是“所見即所得”的要求。

2. 條件控制。這是一個很棘手的問題。一個簡單的例子是某物流陪送系統中，物品數低于一定值的要高亮顯示。不過對于一個具體復雜顯示邏輯的情況，條件控制似乎不可避免。當你把類似于<if condition=”$count <＝ 40”><then><span class=”highlight”>count </span></then></if>引入，就象我們當初在asp和php中所做得一樣，我們將不得不再一次面對scriptlet嵌入網頁所遇到的問題。我相信你和我一樣并不認為這是一個好得的編寫方式。實際上并非所有的模板技術都使用條件控制，很多已有的應用如php上中的以及我曾見過一個基于asp.net的應用，當然還有java的jdynamite。這樣網頁上沒有任何邏輯，不過這樣做的代價是把高亮顯示的選擇控制移交給編程代碼。你必需做個選擇。也許你也象我一樣既不想在網頁中使用條件控制，也不想在代碼中寫html標記，但是這個顯示邏輯是無可逃避的（如果你不想被你的老板抄魷魚的話），一個可行的方法是用css，在編程代碼中決定采用哪個css樣式。特別是css2技術，其selector機制，可以根據html類型甚至是element的attributes來apply不同的樣式。

3. 迭代（循環）。在網頁上顯示一個數據表單是一個很基本的要求，使用集合標簽將不可避免，不過幸運的是，它通常很簡單，而且夠用。特別值得一提的是php的模板技術和jdynamite技術利用html的注釋標簽很簡單的實現了它，又保持了“所見既所得”的特性。

下面是一些技術的比較：

 

2.       模板文件：

模板文件指包含了模板語言的文本文件。

模板文件由于其模板語言的兼容性導致不同結果。與html兼容性的模板文件只是一個資源文件，其具有良好的復用性和維護性。例如jdynamite的模板文件不但可以在不同的項目中復用，甚至可以和php程序的模板文件互用。而如velocity的非兼容模板文件，由于其事實上是一個腳本程序，復用性和可維護性大大降低。

3.       擁有動態數據的數據對象：

模板文件包含的是靜態內容，那么其所需的動態數據就需要另外提供。根據提供數據方式的不同可以分為3種：

1.       map：利用key/value來定位。這個是最常見的技術。如velocity的velocitycontext就是包含了map對象。

 

2.       dom：直接操作dom數據對象，如xslt利用xpath技術。

3.       pojo：直接利用反射取得dto對象，利用javabean機制取得數據。如tapestry。

4.       模板引擎：

模板引擎的工作分為三步：

1. 取得模板文件并確認其中的模板語言符合規范。

比如velocity，確定#if有對應得#end等。xml＋xslt的模型中，xml文件標簽是否完整等。在完成這些工作后，模板引擎通常會把模板文件解析成一顆節點樹（包含模板文件的靜態內容節點和模板引擎所定義的特殊節點）。

2. 取得數據對象。

        該數據對象一般通過程序傳遞引用實現。現有的大量框架在程序底層完成，處理方式也各自不同，有兩種技術分別為推技術和拉技術。推技術：controller調用set方法把動態數據注入，模板引擎通過get方法獲得，典型代表：struts；拉技術：模板引擎根據配置信息，找到與view對應的model，調用model的get方法取得數據，典型代表：tapestry。

3. 合并模板文件（靜態內容）和數據對象（動態內容），并生成最終頁面。

        合并的機制一般如下，模板引擎遍歷這顆節點樹的每一個節點，并render該節點，遇到靜態內容節點按正常輸入，遇到特殊節點就從數據對象中去得對應值，并執行其表達式語句（如果有的話）。

以下詳細說明：

 

三、jsp技術分析

       1. jsp技術：

       jsp，一個偽裝后的servlet。web server會對任何一個jsp都生成一個對應jsp類，打開這個類，就會發現，jsp提供的是一個代碼生成機制，把jsp文件中所有的scriptlet原封不動的copy的到生成的jsp類中，同時調用println把所有的html標簽輸出。

 

       2. taglib技術：

taglib作為jsp之上的輔助技術，其工作本質依托與jsp技術，也是自定義標簽翻譯成java代碼，不過這次和jsp略有不同，它還要經過幾個過程。

先來看一下，實現一個tag的2個要點：

1. 提供屬性的set方法，此后這個屬性就可以在jsp頁面設置。以jstl標簽為例 c:out value=""/，這個value就是jsp數據到tag之間的入口。所以tag里面必須有一個setvalue方法，具體的屬性可以不叫value。例如setvalue(string data){this.data = data;}。這個“value”的名稱是在tld里定義的。取什么名字都可以，只需tag里提供相應的set方法即可。

2. 處理 dostarttag 或 doendtag 。這兩個方法是 tagsupport提供的。還是以c:out value=""/為例，當jsp解析這個標簽的時候，在“<”處觸發 dostarttag 事件，在“>”時觸發 doendtag 事件。通常在 dostarttag 里進行邏輯操作，在 doendtag 里控制輸出。

  在處理tag的時候：

  0. 從tagpool中取得對應tag。

1.     為該tag設置頁面上下文。

2.     為該tag設置其父tag，如果沒有就為null。

3.     調用setter方法傳入標簽屬性值tag，如果該標簽沒有屬性，此步跳過。

4.     調用dostarttag方法，取的返回值。

5.     如果該標簽有body，根據dostarttag返回值確定是否pop該標簽內容。如果要pop其body，則：setbodycontent()，在之后，doinitbody()。如果該標簽沒有body，此步跳過。

6.     調用doendtag()以確定是否跳過頁面剩下部分。

7.     最后把tag類返還給tagpool。

 

   taglib技術提供兩個機制，body和non-body導致了taglib的出現了兩個分支：display tag和control tag， 前者在java code中嵌入了html標簽，相當與一個web component，而后者則是另一種模板腳本。

 

四、兩種技術方案的比較：

       1. 技術學習難易度

模板技術。使用模板技術，第一點就是必須學習模板語言，尤其是強控制的模板語言。于是模板語言本身的友好性變的尤為重要。以下依據友好性，表現力以及復用性三點為主基點比較了一下幾種模板技術。

 

在jsp中大量的使用taglib，能夠使得jsp的頁面結構良好，更符合xml格式，而且能夠重用一些頁面元素。但taglib的編譯之后的代碼龐大而雜亂。tablib很不靈活，能完成的事情很有限。tablib代碼本身的可重用性受到tagsupport定義的限制，不是很好。 另外是，我不得不承認的一件事是，taglib的編寫本身不是一件愉快的事情，事實我個人很反對這種開發方式。

 

       2. 技術使用難易度

       模板技術：模板技術本身脫離了web環境，可以在不啟動web server得情況下進行開發和測試，一旦出錯詳細的信息易于錯誤的定位。由于模板引擎的控制，頁面中將只處理顯示邏輯（盡管其可能很復雜）

       jsp技術：工作在web環境下，開發測試一定要運行web server。此外，一些taglib能夠產生新的標簽，頁面的最終布局也必須在web環境下才可以確定。測試時出錯信息不明確，特別是taglib得存在，極不容易定位。由于其本質是程序，很容易在其中寫入業務邏輯，甚至于數據庫連接代碼，造成解耦的不徹底。

 

3. 總結

模板技術更加專注于頁面的顯示邏輯，有效幫助開發人員分離視圖和控制器。在學習，開發和測試都更加容易。