淺析JSP技術單處理和多任務處理
JSP技術單處理和多任務處理
如前所述，理想狀態(tài)下，設計師應該能夠執(zhí)行單獨處理，只關注圖形設計，而開發(fā)人員應該能夠?qū)⒆⒁饬性诰幊躺稀Ｒ虼?，設計師可以在將頁面轉(zhuǎn)換為適合應用程序的格式后，再對其進行處理。對于 JSP 頁面來說，將頁面轉(zhuǎn)換為適合應用程序的格式就是指向頁面導入 JavaBeans、插入內(nèi)聯(lián)編碼并添加自定義標記庫。問題是有些設計師使用的是 HTML 編輯器，比如 HoTMetaL、Macromedia Dreamweaver 或 FrontPage，這些編輯器無法識別代碼 scriptlets 或標記庫，這意味著設計師實際上只收到了頁面的一部分。想象一下，標記庫或代碼片段只生成了表的若干行，或是頁面中其他格式化的細節(jié)，這是多么麻煩的事情。設計師使用了不兼容的 HTML 編輯器，無法看到這些元素的外觀。在開發(fā)人員完成編碼后，設計師不能輕松地對頁面進行修改，這時，不僅沒有清晰地劃分角色，JSP 編碼實際上將這兩種角色合二為一：開發(fā)人員必須執(zhí)行多個任務，必須擔當開發(fā)人員、設計師以及其他角色。
如果您仍然對此表示懷疑，那么請下載 J2EE Reference Implementation 并將其中一個附帶的 JSP 頁面加載到一個 WYSIWYG HTML 編輯器，例如 Dreamweaver.頁面立即被一些黃色區(qū)域填充，告訴您頁面中包含的所有 “錯誤” 標記。當然，黃色內(nèi)容來自于 JSP 標記和代碼，而不是頁面出現(xiàn)了什么真正的錯誤。
迄今為止，尚未出現(xiàn)支持 JSP 功能的 WYSIWYG 編輯器，我也沒有聽說過任何與此相關的項目。盡管模板引擎也具有相同的問題，但是很多基于 Java 的解決方案，例如我最喜歡的 Enhydra，都允許您將標記頁面作為輸入提供給表示技術。在這種情況下，設計師可以根據(jù)需要頻繁地進行修改，并重新提供標記頁面。運行表示技術的引擎或編譯程序?qū)擞涰撁孓D(zhuǎn)換為適當?shù)母袷?，并且不需要修改任何代碼（典型情況下）。最終獲得了理想的結(jié)果：設計師和開發(fā)人員各司其職。
因此，要注意 JSP技術作出的承諾和它實際交付的實現(xiàn)。在實際中，要在一個 JSP技術驅(qū)動的環(huán)境下發(fā)揮功效，必須讓開發(fā)人員處理大部分標記，或至少讓設計師學習一些 JSP 編碼。
HTML和XML
JSP技術最嚴重的缺陷之一（也是經(jīng)常被忽視的一個缺陷）就是它與 XML 不兼容。更確切地說，并且特別針對 HTML 領域，JSP 頁面不要求具備 XHTML 兼容性。XHTML 是一個 World Wide Web Consortium （W3C） 規(guī)范，目前正在取代 HTML 4.0.XHTML 在實現(xiàn)格式良好的 XML 文檔方面定義了 HTML 標記集。例如，<br> 標記必須被轉(zhuǎn)換為 <br/> 才能確保 XML 兼容性（如果這個例子沒有解釋清楚的話，可以查閱 參考資料 列出的 XML 規(guī)范，以及關于 XHTML 的 developerWorks 文章）。同樣的規(guī)則適用于圖像標記，并且在 XHTML 1.1（即將到來）中，大部分字體屬性和其他樣式被移入到 CSS 樣式表中。另外，大多數(shù)標準 HTML 文檔可以輕松地轉(zhuǎn)換為 XHTML 1.0，這意味著可以使用任何與 XML 兼容的解析器讀取，例如 Apache Xerces，并且可以作為 XML 進行處理。
您會問 “這有什么關系呢？”。答案是關系重大。因為 XML 正在快速成為一個在應用程序之間和應用程序內(nèi)部進行通信的全球標準。使用 XML 格式傳遞書籍，可以讓任何使用基本 XML 數(shù)據(jù)綁定功能的應用程序輕松地使用您的應用程序的數(shù)據(jù)。想象一下，通過將您的數(shù)據(jù)遷移到 XML 格式，您就可以與信用卡公司進行網(wǎng)上交易！多數(shù)情況下，您的數(shù)據(jù)表示還需要與其他公司進行交互。最常見的情況是門戶應用程序，它接受來自各種提供者的內(nèi)容（例如，天氣信息、股票報價和新聞），通常附帶有提供者的標記。然而，由于 JSP 頁面將代碼和自定義標記庫相混合，因此無法在這種環(huán)境下良好地工作。
JSP 頁面很少具有格式良好的 XML 文檔，并且不重視是否符合 XHTML，而 XHTML 這種標記語言并不允許使用各種 JSP 自定義標記庫。然而，更重要的是，插入到 JSP 頁面的代碼片段并不屬于任何標記形式，因此當另一個應用程序處理它們時，將產(chǎn)生解析器加載錯誤。
在您提出質(zhì)疑之前，讓我們先了解一下整個情況。如果應用程序允許 JSP 頁面由初始客戶機處理，結(jié)果將產(chǎn)生純 HTML（或 WML、VoXML 等）。然而，大多數(shù)請求這個數(shù)據(jù)的應用程序使用了一定程度的緩存，因為網(wǎng)絡往返開銷很昂貴。在這些情況下，緩存過的頁面將返回過時的數(shù)據(jù)。因此，您可能更愿意返回與 XML 兼容的結(jié)果，最好使用靜態(tài)的形式。而 JSP技術在這些情況下無能為力；JSP 頁面必須始終 在運行時進行處理，以去掉 JSP 代碼 scriptlets 和標記庫。
看看最關鍵的考驗：其他一些表示技術能做到這一點嗎？答案是可以。這個領域最權威的領導者是 Apache Cocoon 項目，它完全建立在 XML 和一個 XSLT 樣式表應用程序（可以在運行時或靜態(tài)狀態(tài)下應用）的基礎之上。由于 XML Server Pages（在 Cocoon 框架中稱為 XSP）實際上是 XML 文檔，因此始終與 XML 兼容。像 Tea 和 Enhydra XMLC 等允許輸入純標記語言頁面的技術也可以做到這點，雖然它們的目的并不在此。在這些情況下，用戶可以使用 XHTML 或標準的 HTML.此外，這比 JSP技術要好，因為 JSP 不能 靜態(tài)地實現(xiàn)格式良好的 XML.
【編輯推薦】
