JSP 的擁護者會很快告訴您 JSP 標記庫 可以幫助您避免這個問題標記庫允許將自定義標記（例如 ﹤AUTHORS /﹥）添加到 JSP 頁面然後在運行時在標記庫內將其解析為代碼片段
使用自定義標記和相關的標記庫允許把以上示例轉換為清單 所示的內容
﹤CENTER﹥
﹤TABLE width=
%
CELLPADDING=
CELLSPACING=
border=
BGCOLOR=
#FFFFCC
﹥
﹤ACTORS /﹥
﹤/TABLE﹥
﹤/CENTER﹥
在運行時將執行標記的代碼並把正確的結果插入到頁面中但是這並沒有解決問題反對 JSP 技術的理由並不在於能否 分離內容和表示而是在於是否必須 分離只要 JSP 編碼允許內聯編碼那麼就可以很方便地對內聯代碼進行最後的修改（特別是逼近最後期限時）而不是將代碼轉換為一個標記庫如果這不是真的那麼 Java 語言為何會馬上比 C 和 C++ 更流行Java 禁用了 C 中大量有問題的特性例如指針相加雖然您可以總是強調您不需要 在 C 中執行指針相加或者優秀的程序員將插入代碼 scriptlet我們都知道實際會發生什麼Java 語言是一種更好的選擇因為它嚴禁 使用這些不好的習慣但是 JSP 在這方面更類似於 C允許實現一些非常糟糕的實踐
檢驗 JSP 技術是否成功達到其所述目標的另一種方法是看它能否在實踐中實現這個目標顯然如果認為 JSP 無法實際實現目標這是不公平的大多數模板引擎比如 FreeMarker 和 WebMacro都提供了相同的內聯編碼功能通常附帶了一種類似 Perl 的語言然而諸如 Enhydra 的 XMLC 這樣的技術不 允許進行這種類型的編碼相反這些技術將一個純標記語言頁面作為輸入然後生成 Java 方法這實際上改變了編程流程應用程序並不像 JSP 技術那樣使用頁面從應用程序調用邏輯而是使用方法影響頁面的值（Enhydra）以 Enhydra 為例使用 XMLC 將頁面轉換為一個 DOM 樹然後使用 DOM 的 HTML 綁定更新頁面中的 字段（有關 Enhydra XMLC 的更多信息請查閱 參考資料）
這裡的重點是JSP 技術實現目標的能力遠遠超過 XMLC例如僅僅是允許標記庫這一項就比 XMLC 強很多但是 Sun 規范總體趨向於始終維護向後兼容性或至少在相當長的一段時間內維護向後兼容性JSP 規范的當前版本為 它允許使用 scriptlets因此在未來幾年內 JSP 頁面內都會支持這個特性在深入探究 JSP 編碼之前請注意在其強調的完全分離內容和表示的理念和實際實現之間存在一個很大的缺口它充其量只是假裝分離了用戶界面和驅動應用程序的代碼
單處理和多任務處理
如前所述理想狀態下設計師應該能夠執行單獨處理只關注圖形設計而開發人員應該能夠將注意力集中在編程上因此設計師可以在將頁面轉換為適合應用程序的格式後再對其進行處理對於 JSP 頁面來說將頁面轉換為適合應用程序的格式就是指向頁面導入 JavaBeans插入內聯編碼並添加自定義標記庫問題是有些設計師使用的是 HTML 編輯器比如 HoTMetaLMacromedia Dreamweaver 或 FrontPage這些編輯器無法識別代碼 scriptlets 或標記庫這意味著設計師實際上只收到了頁面的一部分想象一下標記庫或代碼片段只生成了表的若干行或是頁面中其他格式化的細節這是多麼麻煩的事情設計師使用了不兼容的 HTML 編輯器無法看到這些元素的外觀在開發人員完成編碼後設計師不能輕松地對頁面進行修改這時不僅沒有清晰地劃分角色JSP 編碼實際上將這兩種角色合二為一開發人員必須執行多個任務必須擔當開發人員設計師以及其他角色
如果您仍然對此表示懷疑那麼請下載 JEE Reference Implementation 並將其中一個附帶的 JSP 頁面加載到一個 WYSIWYG HTML 編輯器例如 Dreamweaver頁面立即被一些黃色區域填充告訴您頁面中包含的所有 錯誤 標記當然黃色內容來自於 JSP 標記和代碼而不是頁面出現了什麼真正的錯誤
迄今為止尚未出現支持 JSP 功能的 WYSIWYG 編輯器我也沒有聽說過任何與此相關的項目盡管模板引擎也具有相同的問題但是很多基於 Java 的解決方案例如我最喜歡的 Enhydra都允許您將標記頁面作為輸入提供給表示技術在這種情況下設計師可以根據需要頻繁地進行修改並重新提供標記頁面運行表示技術的引擎或編譯程序將標記頁面轉換為適當的格式並且不需要修改任何代碼（典型情況下）最終獲得了理想的結果設計師和開發人員各司其職
因此要注意 JSP 技術作出的承諾和它實際交付的實現在實際中要在一個 JSP 技術驅動的環境下發揮功效必須讓開發人員處理大部分標記或至少讓設計師學習一些 JSP 編碼
HTML 和 XML
JSP 技術最嚴重的缺陷之一（也是經常被忽視的一個缺陷）就是它與 XML 不兼容更確切地說並且特別針對 HTML 領域JSP 頁面不要求具備 XHTML 兼容性XHTML 是一個 World Wide Web Consortium （WC） 規范目前正在取代 HTML XHTML 在實現格式良好的 XML 文檔方面定義了 HTML 標記集例如標記必須被轉換才能確保 XML 兼容性（如果這個例子沒有解釋清楚的話可以查閱 參考資料 列出的 XML 規范以及關於 XHTML 的 developerWorks 文章）同樣的規則適用於圖像標記並且在 XHTML （即將到來）中大部分字體屬性和其他樣式被移入到 CSS 樣式表中另外大多數標准 HTML 文檔可以輕松地轉換為 XHTML 這意味著可以使用任何與 XML 兼容的解析器讀取例如 Apache Xerces並且可以作為 XML 進行處理
您會問 這有什麼關系呢？答案是關系重大因為 XML 正在快速成為一個在應用程序之間和應用程序內部進行通信的全球標准使用 XML 格式傳遞書籍可以讓任何使用基本 XML 數據綁定功能的應用程序輕松地使用您的應用程序的數據想象一下通過將您的數據遷移到 XML 格式您就可以與信用卡公司進行網上交易！多數情況下您的數據表示還需要與其他公司進行交互最常見的情況是門戶應用程序它接受來自各種提供者的內容（例如天氣信息股票報價和新聞）通常附帶有提供者的標記然而由於 JSP 頁面將代碼和自定義標記庫相混合因此無法在這種環境下良好地工作
JSP 頁面很少具有格式良好的 XML 文檔並且不重視是否符合 XHTML而 XHTML 這種標記語言並不允許使用各種 JSP 自定義標記庫然而更重要的是插入到 JSP 頁面的代碼片段並不屬於任何標記形式因此當另一個應用程序處理它們時將產生解析器加載錯誤
在您提出質疑之前讓我們先了解一下整個情況如果應用程序允許 JSP 頁面由初始客戶機處理結果將產生純 HTML（或 WMLVoXML 等）然而大多數請求這個數據的應用程序使用了一定程度的緩存因為網絡往返開銷很昂貴在這些情況下緩存過的頁面將返回過時的數據因此您可能更願意返回與 XML 兼容的結果最好使用靜態的形式而 JSP 技術在這些情況下無能為力JSP 頁面必須始終 在運行時進行處理以去掉 JSP 代碼 scriptlets 和標記庫
看看最關鍵的考驗其他一些表示技術能做到這一點嗎？答案是可以這個領域最權威的領導者是 Apache Cocoon 項目它完全建立在 XML 和一個 XSLT 樣式表應用程序（可以在運行時或靜態狀態下應用）的基礎之上由於 XML Server Pages（在 Cocoon 框架中稱為 XSP）實際上是 XML 文檔因此始終與 XML 兼容像 Tea 和 Enhydra XMLC 等允許輸入純標記語言頁面的技術也可以做到這點雖然它們的目的並不在此在這些情況下用戶可以使用 XHTML 或標准的 HTML此外這比 JSP 技術要好因為 JSP 不能 靜態地實現格式良好的 XML
結束語
希望我的努力能夠讓您進一步了解JSP 技術的優缺點並且您可以將JSP 技術看作是眾多其他表示技術的替代品現在您可能對整個JEE編程模型也產生了一點懷疑如果您希望進一步研究平台選擇那麼可以在 Apache CocoonEnhydra 和各種模板引擎中尋找 JSP 技術的替代選擇
最後請記住本文並不是建議您使用JSP或避免使用它盡管表面上像是這樣我的目的是鼓勵您對任何技術進行詳細的分析確保它是正確的選擇就像編程模型一樣有時它們是合適的然而有些時候它們並不適合多進行一些比較找到最適合自己的技術並作出明智的決定而不是倉促地決定
[] [] [] [] [] []
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/20764.html
