爪哇咖啡屋 : [轉貼]Template和JSP技術

移植到Velocity (翻譯自 Migrating to Velocity 刊登於 www.onjava.com )

by Jason R. Briggs
translated by 20is87062@cis.nctu.edu.tw">Chen-en Lu (陸振恩)
04/14/2004

在動態網頁的產生有很多的選擇。一般來講，大部分的專案會使用一些公訂的標準，所以如果平台選擇了Java，那可能使用的就是JSP。以很多角度來看這種選擇是合理的：新進員工可能對一個標準比較有經驗；很多的網頁伺服器有支援JSP，這讓Web平台有較多的選擇；可取得的文件也比較多，因為很多東西別人都做過了。然而，有時候使用標準並不一定是最佳的選擇。也許您希望擁有較多的空間去控制文件的產生；也許無法接受JSP的效率問題；也許公司正在推一個新的技術方向；諸如此類的。Velocity是一個簡單有效率且功能強大的樣板引擎(Template Engine)，可以用來取代目前Java中動態網頁產生的標準JSP。某些方面 它提供優於JSP的執行效能，並且它也帶給網頁開發者一個新的分離程式碼跟內容的的全新思維。

唯一的不利因素是如果已經存在了一個JSP-based的專案，而且又有較沒有經驗的團隊且已經對JSP有所接觸，移植到Velocity本身就有所挑戰。在這邊篇文章中，我試著移除這個障礙，用些較簡單的Velocity延伸，來降低切換到Velocity所帶來的痛苦。

一些背景

大約兩年前，我接手了由北歐的公司所寫的一個一般大小，Servlet-based的系統 (並不是所有北歐國家所寫的都有linux的品質)。這系統是用很基本的樣板引擎 (template engine)，但也有很多的html嵌在文件中。事實上裡面有一大長串的不良設計，還有很多噁心的程式碼在其中 (包括了"一手包辦"的巨型method的寫作方法)，這些糾結的程式碼絕對會讓接手的程式員做惡夢。

考量到原有系統的限制，還有公司希望有更完整的需求。我下定決心廢棄掉99%的程式碼，重新寫過，從這個潦草的專案中重新設計了一個新的J2EE系統。新系統現在已經跑了幾乎一年了，並且只有少少的零星狀況。這不只大大增加了維護性，工作也變得快樂許多。

最近，即使這不是很主流的觀點，但我發現我變的不能滿足原本用JSP去實作Web及WAP的網頁的方法。原本的設計是希望越接近MVC pattern越好，但Java程式碼嵌在網頁中並不總是能那麼容易達到這個需求。這個工作在使用JSTL (Java standard tag library)之後好像比較容易些。但必然地，我們會發現有些事情光靠JSTL是無法滿足的，所以可能會寫一個屬於自己的Taglib去達到我們想要的需求。然後卻發現有一些物件您需要在頁面中 直接使用但卻不能用，除非用一些java程式碼把我們的taglib包裝起來。或更常見的，因為要呼叫一些方法，但由於時間的限制，就直接的使用java程式碼去呼叫，只求功能上是可以達到最後要求就好了，但絕對不如剛開始開發時所想的那麼優雅。

接受挑戰

重新評估網頁端的技術變的越來越重要了，因為Servlet Container在處理 JSP是以一種較費時的方式(鮮為人知的"開太多檔"的問題)，在評估了數個選擇之後，因為以下幾個因素我決定使用Velocity：

1. 公開程式碼 — 不管這對其他人來講是不是重要的考量，但是我主要是做linux的業務，所以開放原始碼會是我的首要考量。
2. 效能 — 在我對較簡單的網頁做的初步測試發現，Velocity擁有優於JSP大概35%至45%的效能。而對於較複雜的網頁，這個差距就比較縮小
   (且在加入各種因素在其中時，差距大概掉到5%左右)，但這個效能上的提升還是存在的。
3. 優雅 — Velocity的文法簡單而且實用。要加一些指令在其中(在Velocity中叫directive)也是非常的直覺簡單，完全沒有違反簡單的原則。

我也贊成Velocity的觀點：如果把一個JSP/JSTL的網頁交給網頁設計者跟Velocity比起來只會更難而不會更容易。(JSP/JSTL的缺點是已經假設網頁會是XHTML的格式的，也就是用XML當作動態網頁產生的格式，這並不會讓非技術的設計人員會有好日子過)。

如何運作

在Velocity中，每一個頁面(或是您喜歡的話，也可說是每一群頁面)，就提供一個Servlet。您的Servlet提供所有這個頁面所需要的資料，把它放在一個環境(context)中，最後Velocity會根據環境使用樣板(template)把整個網頁繪製出來。而樣板會包含HTML的標籤以及Velocity的directive— 沒有 Java程式碼。

這當然就是它實用的地方，因為它嚴格的強迫我們不能使用任何的程式碼在樣板之中，也簡化了頁面 — 我個人認為這是JSP網頁無法做到的。

跟JSP做一個比較：我們使用JavaBeans來盡可能的隱藏Java程式碼。我們使用JSP的標籤 useBean ，並且在使用它們前設定對這些beans的值，再透過JSTL的標籤來取得這些值：

<jsp:useBean id="comp" scope="session"
class="com.lateralnz.comp.view.CompDefBean" />
<jsp:setProperty name="comp"
property="someprop" value="someval" />
...
...
<c:forEach var="comp" items="${comps.iterator}">
<tr>
<td class="list">
<c:out value="${comp.compCode}" />
</td>
...

可以想像的，直接把JSP轉成Velocity會帶來一定數量的苦工。若帶領的是一個較沒經驗的團隊，更不用說所連帶的學習曲線。時間永遠是一個問題，即使專案不是大到無法想像， 但我們依然還是沒有資源可以把上百個JSP的頁面轉換到另一個新技術，尤其是用一個完全不一樣的新技術。因此，我決定使用漸進的方式轉換到Velocity，採取一個比較好掌握的方法。

加進JSP沒有的功能

第一步是允許Velocity樣板可以以跟JSP相同的方法被呼叫。首先我們先產生一個基本的Servlet (VMServlet)並設定一個mapping，用"*.vm"當做url-pattern:

<servlet-mapping>
<servlet-name>vm</servlet-name>
<url-pattern>*.vm</url-pattern>
</servlet-mapping>

意思是 http://mydomain.com/mypath/test.vm 會被當作一個標準的Servlet傳給VMServlet。而Servlet的標準方法( doGet, doPost )會去呼叫 VMServlet.processRequest ，在其中會把一些隱含物件加入Velocity的context中 、讀取樣板、並產生最終的結果。

protected void processRequest(
HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {

這裡是透過Velocity標準方法去讀取樣板的部分 (樣板會被引擎所快取)：

  String templateName = request.getServletPath();
Template tmp = ve.getTemplate(templateName);
VelocityContext ctx = new VelocityContext();

Web環境的路徑、session、jsessionid，還有servlet request都會加進context之中 (這些都是在JSP中常用的物件)：

  HttpSession session = request.getSession(true);
ctx.put("contextPath",
request.getContextPath());
ctx.put("session", session);
ctx.put("jsessionid", JSESSIONID_STR +
session.getId());
ctx.put("request", request);

最後一步就是繪製出結果，使用 PrintWriter ，Velocity Context ，還有template:

  response.setContentType(contentType);
PrintWriter out = response.getWriter();
tmp.merge(ctx, out);