JSP標記庫

簡介：JavaServer Pages（JSP）技術是用於開發 Web 應用程式的優秀體繫結構，但它的最重要的實用技 術之一 ― 定製標記庫（custom tag library）― 卻常常未被充分利用。標記庫實用技術未被充分利用 的主要原因不是技術上的，而是語言上的。標記庫生產者和消費者說的不是相同的語言。JSP 專家和顧 問 Noel J. Bergman 揭示了問題的本質並提供了一些可行的解決方案。

將底層內容模型與表示分離是件好事，這在 Web 應用程式開發人員中間得到了普遍的認同。在多數大型 開發工程中，程式員負責實現後端，表示則留給一名或多名 Web 頁面設計人員去做。這種分工確保了最 終產品技術可靠、同時表示良好，但它肯定要求兩個小組有效地溝通和合作。考慮到每個小組工作時所 依賴的知識基礎不同，而且關注的問題也極其不同，這可能是一個挑戰。

在引入 JavaServer Pages（JSP）規範的版本 1.1 中的定製標記庫之前，必須使用 JSP 指令碼元素來 在 JSP 頁面內提供任意的定製功能性。顯式地使用指令碼元素違背了模型與表示相分離的原則。顯式地使 用指令碼元素還要求，如果 Web 頁面設計人員要做任何“從 JavaBean 組件中檢索屬性”之外 的事情，他就要具有 Java 編程經驗。這引起了人們對 JSP 頁面內指令碼元素的使用的廣泛關注，這接著 導致了人們進行替代解決方案的開發。

一個經典的解決方案是開發出了模型-視圖-控制器（Model-View-Controller）類型的使用模型。在 這種使用模型中，應用程式的智能部分放置在 servlet 和 bean 中，JSP 頁面只負責檢索內容並將它呈 現出來。Jakarta Struts 就是這種模型的一個很好的樣本。別的開發小組已經建立了諸如 Velocity 內 容引擎或 Apache 的 Cocoon 工程這樣的替代技術。

雖然這些解決方案各有千秋，但它們通常是非標準的，而且忽視了 JSP 技術的持續發展。我們將在 本文著重討論 JSP 技術中使用最不充分的實用技術之一：定製標記庫。我的目標是改變您對定製標記庫 （更具體地說，是標記設計）的思考方式。我的討論將從澄清關於 JSP 技術及其某些替代解決方案的一 些誤解開始，然後再轉到中心論題上。

JSP 技術：誤解和替代解決方案

關於 JSP 技術的常見誤解有很多，其中一些誤解通常已經過時，而且還嚇走了潛在的使用者。表 1 列 出了一些最常見的誤解。

表 1. JSP：誤解

誤解	真相
JSP 頁面要求以指令碼元素的形式對代碼模型和表示進行混合。	正如我們將在下一部分討論的那樣，標記庫證明了這種說法是錯誤的。
JSP 頁面指令碼編製實際上就是 Java 編程。	這隻是部分正確的。自版本 1.0 以來，JSP 規範就已允許使用多種指令碼語言。然而， 這一功能並未得到廣泛實現。IBM WebSphere 允許使用多種指令碼語言，而且其底層技術是以開放原始碼 方式發布的（請參閱旁註 “替代解決方案的變通辦法”）。此外，通過 JSP 標記庫， Velocity 範本語言（Velocity template language）也是可用的。
JSP 頁面不好，因為它允許進行指令碼編製。	這一抱怨在最近對 JSP 規範的修改中得到瞭解決。JSP 規範的當前發行版為標記庫引 入了一個新的概念。標記庫可以包含一個驗證方法，以對任何要使用該標記庫的 JSP 頁面進行驗證。 在 2001 年科羅拉多軟體峰會（Colorado Software Summit 2001）上，Mark Kolb 示範了一個簡單的標 記庫驗證器，這個標記庫驗證器驗證了 JSP 頁面完全可以不要指令碼（請參閱 參考資料）。

上面列出的每一種誤解都曾經至少是部分正確的。不過，JSP 技術是 J2EE 規範的主要部分而且得到 了廣泛使用。因此，會有很多廠商通過各種努力發展 JSP 技術並使之成熟，以解決使用者所關心的問題。 這是使用標準技術、而不使用專門的解決方案的好處之一。

雖然如此，在負責部署 Web 應用程式的經理們中間還是頑固地存在一種常見的思想。由於不瞭解誤解背 後的真相，又被告知 JSP 技術混合了編程和表示，這些經理們的第一反應是說他們將尋求 JSP 的替代 解決方案，例如 Velocity。所以問題就是，像 Velocity 之類的解決方案真的能夠解決問題嗎？

Velocity 文檔敘述說，它“允許任何人使用這種簡單但強大的範本語言來引用 Java 代碼中定 義的對象”，文檔還敘述說“Velocity 範本語言（VTL）旨在提供一種最容易、最簡單而且 最乾淨的方式，將動態內容結合到 Web 頁面。即便是只有一點點或完全沒有編程經驗的 Web 頁面設計 人員，也應該很快就能夠用 VTL 來將動態內容整合到 Web 網站。”換句話說，Velocity 並未將 編程從表示中除去；而是要求使用者學習一種新的專門的指令碼語言。由於 Velocity 要求 Web 頁面設計人 員學習 Velocity 範本語言，它未能消除“內容和表示混合”的問題。

Velocity 只是市面上眾多模板引擎的一個例子，但是，市面上的多數模板引擎，如 Velocity，都要 求具有一定的前端編程技能。

JSP 技術的另一個流行的替代解決方案是 Cocoon 工程。Cocoon 是一種討人喜歡的技術，它使用 XML 作為它的來源資料格式。XSLT 轉換的作用是將 XML 內容轉換成適合於使用者代理程式的格式，例如，適合 於瀏覽器的 HTML。Cocoon 有它自己的稱為 XSP 的動態網頁面格式。XSP 是 JSP 的近親，但它工作在 Cocoon 環境中。XSL 會廣泛存在的原因是，沒有一種很好的辦法將來自 JSP 頁面的 XML 輸出通過 Cocoon 發送到瀏覽器。早期 servlet 容器中的 servlet 連結機制無法勝任這一工作。不過，現在 Sun 已經引入了一種新的 servlet 過濾器機制，這種機制完全有能力將來自任意的 servlet 的 XML 輸出通 過一系列過濾器發送出去。從這個角度看，對 XSP 的需要明顯降低了，需要 Cocoon 工程來提供其 XSLT 轉換引擎作為 servlet 過濾器也變得明確起來。

關鍵的是，JSP 技術正在不斷髮展，以滿足它的使用者的需求。這意味著對 JSP 技術的任何評估都必 須考慮到對其最新規範的審慎評論。即使是幾個月前的評論和社論也會因出現了新的發展而顯得過時（ 請參閱 參考資料）。