簡介：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 技術的任何評估都必 須考慮到對其最新規范的審慎評論。即使是幾個月前的評論和社論也會因出現了新的發展而顯得過時（ 請參閱 參考資料）。
