Java Web Application中，頁面生成部分是最繁瑣、令人頭痛的部分。
其它的層都可以很好的結構化，唯有頁面生成部分的結構很散亂。
本文首先介紹并比較各種頁面生成技術，然后具體介紹一個把PHP 模板移植到Java的開源項目??fastm。
我希望fastm能夠幫助廣大Java Web程序員從繁瑣的頁面開發(fā)工作中解脫出來。
本文所指的頁面是XML，HTML，WML等能在瀏覽器中顯示的Web頁面。
按照頁面處理邏輯的位置劃分，頁面生成技術可以分為兩大類：
（1）一類是，頁面處理邏輯包含在頁面本身里面，而不是在Java Code里面。比如，JSP + TagLib, Velocity, XML + XSLT（處理邏輯在XSL文件中），Tapestry（Tapestry的情況比較復雜）等。
這一類技術中，由于頁面處理邏輯不在Java Code里面，頁面組件的結構和可重用性都不是很好。因為，結構和可重用性需要“對象” 、“類”、“包”等面向對象的特性。
（2）另一類是，頁面處理邏輯不在頁面本身里面，而是在Java Code里面。比如XMLC，DOM + XPath，PHP Template Java Port等。
這一類技術中，由于處理邏輯在Java Code里面，所以，Java程序的結構和可重用性能有多好，頁面組件的結構和可重用性就能有多好。
下面分別講解和比較這些頁面生成技術：
JSP + TagLib 是Sun公司的頁面生成技術規(guī)范。
優(yōu)點：
權威，規(guī)范，使用者眾多，第三方提供了大量的TagLib支持。
而且，JSP本質上是Servlet。其中的Java Code部分非常強大而且靈活，能夠達到Java語言最大的靈活度。
TagLib能夠達到一定程度上的頁面元素重用。TagLib還能夠在一定程度上，幫助驅逐JSP頁面的Java Code“污染”部分。J
缺點：
JSP的缺點很明顯。Java Code和HTML頁面內容混雜在一起，這是讓廣大程序員最頭疼的Java Code Pollution問題。即使用TagLib也不能完全解決這個問題。
而且，程序員和頁面編輯人員無法在同一個文件上工作。每次頁面編輯人員編好了HTML頁面，程序員必須重新加入Java Code和TagLib。
而HTML頁面一旦加入了Java Code和TagLib，就無法在頁面編輯器（Dream Weaver, Front Page）中正確顯示了。程序不跑起來，就無法看到JSP頁面的頁面結構、顯示風格和內容。
關于效率，靈活性，結構性，可重用性，JSP + TagLib是一個兩難的選擇。
在JSP中大量的使用TagLib，能夠使得JSP的頁面結構良好，更符合XML格式，而且能夠重用一些頁面元素。但TagLib的編譯之后的代碼龐大而雜亂，而且運行效率很低，嚴重影響響應速度。TabLib很不靈活，能完成的事情很有限。TabLib代碼本身的可重用性受到TagSupport定義的限制，不是很好。TagLib的編寫不是一件愉快的事情。J
如果在JSP中大量使用Java Code，那么頁面的結構性會很差，難以管理。所有的代碼都在同一個文件中，遇到大的HTML頁面，簡直如同噩夢一般。從一個左括號“{”找到對應的右括號“}”都變成很痛苦的一件事情。鑲嵌在Java Code中間的HTML元素的是無法重用的。所以，JSP中的Java Code根本就沒有可重用性（include file除外）。
http://jakarta.apache.org/velocity/
Velocity是一種模板處理工具。Velocity模板由HTML中夾雜一些Velocity腳本語言或變量定義組成。
優(yōu)點：
Velocity的腳本語言（以#開始）或變量定義（用$標志）和HTML、WML、XML等的元素定義不沖突。
簡單的Velocity頁面（不包含分支和循環(huán)邏輯）能夠在頁面編輯器（Dream Weaver, Front Page）中正確顯示。
缺點：
同樣，Velocity模板的頁面處理邏輯和HTML元素混雜在一起。如果Velocity頁面的邏輯復雜的話（比如有循環(huán)和判斷分支），那么該Velocity頁面同樣不能在頁面編輯器（Dream Weaver, Front Page）中正確顯示。
遇到大的HTML頁面，從一個 “#if”找到對應的 “#end”也是很痛苦的一件事情。鑲嵌在Velocity腳本語言中間的HTML元素的是無法重用的。所以，Velocity模板中的腳本代碼和HTML元素也不具有可重用性（include file除外）。
Cocoon項目采用XML + XSLT的方法。Java程序只需要輸出XML數(shù)據(jù)，Cocoon框架調用XSL文件把XML數(shù)據(jù)轉換成HTML、WML等文件。
優(yōu)點：
程序員省事了，不用考慮頁面結構和顯示方式，只需要輸出XML數(shù)據(jù)即可。
同一份XML數(shù)據(jù)，只要定義不同的XSL文件，就能夠很方便地產生不同顯示風格的頁面。
在內容和顯示風格分離的方面，XML + XSLT這種方法做得最好。
缺點：
慢。XSLT的速度比較慢。
由于沒有HTML文件，根本看不到頁面結構、顯示風格和內容。只有程序跑起來，XSLT轉換之后，才能
XSL語法比較難以掌握，由于沒有“所見即所得”編輯工具，學習成本較高，遠遠高于HTML的學習成本。
http://jakarta.apache.org/tapestry/
Tapestry擴展了HTML元素的定義。Tapestry用這些擴展的HTML元素屬性來表示處理邏輯（循環(huán)，分支等）、組件定義和變量定義。
優(yōu)點：
整個Tapestry頁面文件都是HTML元素，能夠在頁面編輯器（Dream Weaver, Front Page）中顯示。但顯示的樣子是否正確，是另一回事，和包含的處理邏輯（循環(huán)，分支等）的復雜度相關。大致和Velocity的情況相似。
Tapestry的頁面組件重用性比較高。
缺點：
復雜。Tapestry的定義和用法都很復雜。由于復雜，所以慢。
我沒有實際使用Tapestry的具體經驗，這里就不繼續(xù)妄加評論了。J
XMLC把HTML、WML等文件編譯成一個DOM結構的Java類。程序員不用管頁面，只需要操作這個DOM結構，就可以動態(tài)生成頁面。
XMLC根據(jù)HTML元素的id定義，生成相應結點的操作方法。
優(yōu)點：
頁面是純粹的HTML，沒有任何邏輯。能夠在頁面編輯器（Dream Weaver, Front Page）中正確顯示。
Java Code處理DOM結構，代碼結構和可重用性良好。DOM節(jié)點即HTML元素，即頁面組件，也具有很好的可重用性，你隨時可以把一個DOM節(jié)點放到任何文檔中的任何位置。
由于是靜態(tài)編譯，沒有動態(tài)解析過程，文檔生成的速度很快。
缺點：
每次修改HTML頁面，必須重新把HTML文件編譯成Java文件。而且，很多HTML都不是良好的XML結構，不能夠正確地編譯成DOM結構。
該DOM結構不能在多線程環(huán)境中重復使用，這就意味著，每一個頁面請求，都需要生成一個單獨的DOM結構，占用內存空間比較大。而且，每個DOM結構使用過之后，也很難清空重置，很難提供給下一個請求使用。在HTML文件比較大的時候，內存的開銷顯著增大。
XMLC有些方面不夠靈活。比如，我們知道，很多Java Scri
<SCRIPT LANGUAGE="Javascri
<!--
function aa{
…
}
//-->
</SCRIPT>
如果Java Scri
前面講了XMLC把HTML靜態(tài)編譯成DOM結構。
我們也可以采用動態(tài)生成DOM結構的方法，然后用XPath定位DOM結點并操作它們。
NekoHTML（http://www.apache.org/~andyc/neko/doc/html/）是一個HTML文檔解析工具。
NekoHTML使用Apache Xerces（http://xml.apache.org/xerces2-j/index.html）的Xerces Native Interface對HTML文檔進行解析，能夠自動補足并修正不符合XML文法的HTML元素，并生成HTML DOM文檔樹。
Apache Xcerse的XPathAPI，可以用XPath方便地定位DOM結構的結點。DOM + XPath的詳細用法請參見NekoHTML的使用文檔。
優(yōu)點：
大致具有上述XMLC方法的優(yōu)點。
沒有靜態(tài)編譯過程，動態(tài)生成DOM結構，及時反映頁面文件的變化。
缺點：
大致具有上述XMLC方法的缺點。
DOM結構的動態(tài)生成比較花時間。我們可以采用這樣的方法解決這個問題，把第一個生成的DOM結構作為標準模板。我們不對標準模板操作，每次請求需要一個DOM結構的時候，我們就從這個標準模板深度拷貝（deep copy）一個新的DOM結構，然后使用這個新的DOM結構。這樣每個HTML文件只需要解析一次，成為標準模板。每次HTML文件更改的時候（這種情況很少），標準模板也跟著更新。
XPath的解析和定位速度不是很快，幾乎每次都要遍歷整個文檔樹。
PHP模板的設計思路很好，PHP模板用XML的Comment注釋部分來定義動態(tài)結構，用{}來標志需要替換的變量部分。
優(yōu)點：
頁面編輯器（Dream Weaver, Front Page）不顯示XML的Comment注釋部分，而且{}符號和XML元素定義不沖突。所以，PHP模板本身符合HTML語法，能在頁面編輯器（Dream Weaver, Front Page）中正確顯示。程序員和頁面編輯人員可以在同一份頁面文件上工作，所見即所得。
簡單，易用，靈活（幾乎和最靈活的JSP Java Code一樣靈活）。具體用法見后面。本文的主要目的就是介紹PHP模板及其Java Port的用法。J
快速。如果采用適當?shù)乃悸罚ū热?/span>fastm的思路J），整個HTML只需要快速地解析一次，生成一個只讀的可多線程重用的模板。
fastm的速度會比JSP + TagLib快。fastm的速度可能會比純粹的JSP慢，也可能更快一些。JSP（即Servlet）把整個頁面一行一行地寫到Socket里面，網絡傳輸?shù)男什桓?。?/span>fastm把整個頁面或者整塊頁面，一次寫到Socket里面，網絡底層協(xié)議盡可以優(yōu)化分塊，達到最好的網絡傳輸效率。
缺點：
比起其它的頁面技術來說，這種技術的缺點很少。
一個需要提到的地方，也是Java Scri
<SCRIPT LANGUAGE="Javascri
<!--
function aa{
…
}
//-->
</SCRIPT>
因為PHP Template采用XML Comment來定義動態(tài)結構，所以我們不能在Java Scri
從各方面來說，我認為這是最好的頁面生成技術。
我的一個同事向我介紹了PHP Template的定義和用法，我產生了濃厚的興趣，并產生了把PHP Template移植到Java的想法。我首先到網上搜索了一下，發(fā)現(xiàn)了JDynamiTe (Java Dynamic Template) （https://sourceforge.net/projects/jdynamite）開源項目。JDynamiTe能夠把PHP模板移植到Java語言。
JDynamiTe的模板定義和PHP Template有些微小的差別，但一樣簡單。我閱讀了JDynamiTe的例子代碼，馬上喜歡上了這種方法。
但我發(fā)現(xiàn)，JDynamiTe有一點不足。和DOM結構的處理過程一樣，JDynamiTe的模板部分和參數(shù)設置部分是合在一起的。JDynamiTe的模板部分不能在多線程中同時使用。
每次JDynamiTe都需要讀取并解析HTML文件，生成一個模板，設值之后，產生結果。處理過后的這個模板就不能再直接使用了（也許可以清空再使用）。
如果HTML文件很大，那么，讀取并解析HTML文件要花費不少時間。
所以，我決定自己實現(xiàn)一個高效率的可重用的PHP Template Java Port。
項目名為fastm（Fast Template的意思。）
fastm的模板定義采用JDynamiTe的模板定義，而且我直接采用JDynamiTe的例子模板文件，作為fastm測試例子的模板文件。Fastm可以說是JDynamiTe的一個Multiple Thread Port。
在fastm里，我把HTML的解析結果文檔 和變量設值部分分開。
每個HTML文件只需要解析一次，生成一個只讀的模板。既然只讀，當然線程安全，任何數(shù)量的線程都可以同時使用這個模板。
以后這個模板只需要和不同的變量設值結合，就可以生成不同的結果。
模板的解析過程，采用按行讀取處理的方式，解析的速度很快。
fastm的頁面定義完全仿照JDynamiTe的PHP頁面定義。我的思路來源是PHP Template和JDynamiTe。我自己原創(chuàng)的東西是fasm的實現(xiàn)，和使用方法。fastm的代碼量很小，采用的技術也很簡單，沒有用任何第三方的軟件，只用了JDK1.4本身的類。
fastm的頁面組織組合能夠達到前所未有的靈活度。我們可以用任意的某個文件的某塊頁面，替換某個文件中的任意位置，用法簡單直觀。（舉例說明）
其它頁面技術（JSP，Velocity等）的<include file> <import file>等方式，只能包括、引入整個文件。而且用法不直觀，容易出錯。程序員必須清楚的記得當前頁面包括了哪些文件，應該為包括的文件聲明哪些變量。
在我目前所知的Java頁面生成技術中，我相信，fastm從各方面來說，是最好的方法??快，易用，靈活，強大。我期望fastm這種頁面生成方式，能夠較好地解決頁面生成技術這個令人頭痛的問題，能夠在全世界的程序員中流行起來。
