摘要：作為一名資深的 Java 技術專家和 Enhydra 支持者,本文作者強烈建議開發人員在選擇 Web 應用程序編程語言時,使用其他可以替代 JavaServer Pages （JSP） servlets 的技術.JSP 技術是Sun 的J2EE 平台和編程模型的一部分,用於解決將單調的內容轉換為外觀優美的表示層時遇到的困難.事實上,並非所有的Web開發人員都對JSP 技術很滿意.由於 Sun 技術出現了很多不同的版本,您可以從眾多表示技術中選擇一種替代技術.本文將深入查看JSP代碼並介紹一些有吸引力的替代選擇.
表示技術專門用於將單調粗糙的Web 內容轉換成帶有漂亮的表示層的內容.JavaServer Pages （JSP） 技術是 Sun 的表示模型,並且是 J2EE 平台的一部分,它獲得了極大的關注.使用 JSP 技術有優點也有缺點.Web 開發人員應該了解這些優缺點,並且知道還有其他代替技術.實際上,現在有很多可供選擇的表示技術.本文先介紹表示技術要解決哪些問題,然後考察 JSP 模型特有的優缺點.
,將介紹一些其他表示技術,它們可以代替 Sun 表示技術.
歷史背景
在深入介紹表示技術之前,有必要了解一下該技術產生的時代背景.就在10 年前,瘦客戶機還是個新鮮事物.我們仍然處於桌面應用程序的時代,使用功能有限的 286 微處理器和現在看來不屑一顧的 14 寸顯示器.時代變了！現在我的台式機只需要運行一個 Web 瀏覽器,伺服器由 Sun、IBM、HP、Compaq 提供,計算、業務邏輯和內容則又由其他公司提供.那麼顯示器呢？現在我們使用的是 21 寸到 25 寸不等、等離子寬屏顯示器.這樣我們就可以看到複雜的 HTML 表示,它們充當這些強大的應用程序的前端.以前的單調界面已經無法滿足需要；我們現在需要使用華麗的圖形、可以移動的圖像、色彩協調的表示,並且要求它能夠加快呈現速度.
前提條件
如今,在羽毛漸豐的 Windows 應用程序經過十年的發展之後,我們還處在表示模式的巨大轉型之中.Visual Basic 和 C 程序員發現他們仍然在使用後端系統或單調的 Windows 應用程序,或是在工具箱中加入了一種具有 Web 能力的語言,例如 Java 語言.如果一個應用程序無法支持至少 3 到 4 種 ML 式語言（例如 HTML、XML 和 WML）,即使不是徹底失敗,也會被認為是很糟糕的.當然,這就表示我們非常重視能輕鬆開發 Web 表示層的能力.
事實證明,使用新的 Internet 以及所有可用的語言（Java、C、Perl、Pascal 和 Ada 等）並不像我們希望的那樣簡單.在後端系統使用編程語言並利用它們生成適合客戶機的標記語言時,出現了大量問題.隨著瀏覽器端的選擇越來越多（例如 DHTML 和 JavaScript 編碼）,Web 領域迫切需要圖形設計知識,以及可以使用標準 HTML 創建複雜界面的工具.但開發應用程序前端的能力無法跟上這些需求的步伐.此時,表示技術 應運而生.
表示技術的專門任務是：將內容（即沒有包含表示細節的數據）轉換為表示,也就是您在手機、PalmPilot 或 Web 瀏覽器看到的各種用戶界面.這些表示技術要解決哪些問題？讓我們來了解一下.
分離和集成
表示技術的主要目的是允許分離內容和表示.換而言之,業務邏輯單元（假設 C 或 Java 等編程語言）不需要使用特定於表示的方式生成數據.數據或內容,按照原始格式返回,沒有進行格式化.表示技術隨後對內容應用格式化或進行表示.最終的結果是各種數據被圖形、格式、色彩和徽標所包圍.
查看清單 1 和清單 2 中的示例,了解一下原始內容和應用了表示技術的內容之間的差異.
清單 1 展示了原始的內容,全部都是數據,可以按照任何方式使用.
| Russell Crowe Tom Hanks Meg Ryan Mary Stuart Masterson Alec Baldwin Ashley Judd Keanu Reeves |
清單 2 要比清單 1 更加複雜,使用表示技術對相同的數據進行了裝飾,並可以立即表示在支持 HTML 的瀏覽器中.
| <HTML> <HEAD> <TITLE>Search Results: Actors</TITLE> </HEAD> <BODY> <H2 ALIGN="center">Search Results: Actors</H2> <CENTER> <HR width="85%"> <TABLE width="50%" CELLPADDING="3" CELLSPACING="3" border="1" BGCOLOR="#FFFFCC"> <TR BGCOLOR="#FFCCCC"> <TH width="50%" ALIGN="center">Last Name</TH> <TH width="50%" ALIGN="center">First Name</TH> </TR> <TR> <TD width="50%">Baldwin</TD> <TD width="50%">Alec</TD> </TR> <TR> <TD width="50%">Crowe</TD> <TD width="50%">Russell</TD> </TR> <TR> <TD width="50%">Hanks</TD> <TD width="50%">Tom</TD> </TR> <TR> <TD width="50%">Judd</TD> <TD width="50%">Ashley</TD> </TR> <TR> <TD width="50%">Masterson</TD> <TD width="50%">Mary Stuart</TD> </TR> <TR> <TD width="50%">Reeves</TD> <TD width="50%">Keanu</TD> </TR> <TR> <TD width="50%">Ryan</TD> <TD width="50%">Meg</TD> </TR> </TABLE> </CENTER> </BODY> </HTML> |
可以看到,清單 1 中的內容更清晰,非專業人員更加容易使用和理解,而清單 2 中的內容特定於瀏覽器表示.很難從中提取數據或將數據用作其他用途.
這個基本的區別,即分離表示和內容而不是集成它們（至少在用戶需要使用信息時）,是任何錶示技術前提,包括 JSP 技術.此外,任何無法實現這個基本目標的表示技術都不能真正體現創建的初衷.
工作和重複工作
除了分離表示和內容外,另一個衡量表示技術的可用性的指標是：能夠消除多少重複的工作.表示和內容的分離也促使內容開發人員之間的角色分離.程序員可以關註上例所示的原始內容,而圖形設計師或網路管理員則關注表示.然而,在獲得圖形設計師設計的表示（或標記）並將它應用到程序員代碼提供的內容中時,角色之間仍然有一定重複.
在最簡單的情況下,設計師提供標記,而開發人員提供代碼並把標記插入到表示技術中.應用程序被 「啟動」,內容魔術般地變成了用戶界面.當然,我們都知道,開發遠遠沒有結束.接下來要重新修訂版本、修改界面,還必須添加新的業務規則.這能真正考驗表示技術的靈活性.雖然很容易更新插入到表示層的原始內容,但是圖形設計師很少能夠輕鬆地編輯他們的初始工作.經常要修改表示層（我們常常按照銷售部門的 「指使」 進行修改）.因此,問題產生了：設計師要修改哪些內容來調整他們的工作？是他們提供給開發人員的原始標記語言頁面嗎？也許不是,
這個頁面很可能插入了自定義標記或代碼（JSP 頁面、模板引擎）,被轉換為一個 Java servlet,或修改為完全無法識別的內容.
設計師通常需要重新設計頁面並重新將其提交給開發人員.然後再由開發人員將頁面重新轉換為特定的格式,以供表示技術使用.或者,設計師必須學習一種腳本編製語言,或至少知道開發人員提供的頁面源代碼中哪部分是違規的.當然,這種方法容易出錯,並且使用起來不安全.當您了解到某種表示技術允許清晰地分離內容和表示后,您應該確保將修改表示層所需的重複工作減至最小.
JSP 技術的承諾
現在,讓我們具體看一下 JSP 編碼.JSP 技術承諾為設計師和開發人員提供他們所需的惟一表示技術.JSP 技術是 J2EE 平台的一部分,這充分展示了 Sun 為其 Java 產品提供的強大支持.為了使您了解這個解決方案的流行程度,請嘗試在 amazon.com 中搜索一下 『JSP』；您將發現大量與 JSP 技術有關的書籍,它會遠遠超過任何單獨一種 Java API.在詳細探討 JSP 技術引發的具體問題之前,您應該清楚地了解這種技術的承諾.
內容和表示
,JSP 技術與內容和表示的分離有關,是 Sun 發布的有關 JSP 頁面的最主要目標.實際上,一些代碼開發人員抱怨將 out.println（"<HTML><HEAD><TITLE>" pageInfo.getTitle（） "</TITLE></HEAD>"）； 鍵入到 servlet,這直接導致了 JSP 的設計.在硬編碼內容中混入運行時變數加重了 servlet 開發人員的負擔,並且使開發人員更加難對錶示層進行修改,即使非常小的修改也是如此.
JSP 技術解決了這個問題,它允許在運行時將普通的 HTML 頁面（後來還包括 WHM 或其他標記語言）編譯到 Java servlet 中,實際上效仿了 out.println（） 範例,而不需要開發人員編寫代碼.它允許您將變數插入到在運行時才進行解釋的頁面.
在一個 JSP 頁面中,清單 2 所示的 HTML 片段應該類似清單 3 中的示例.
| <%@ page import="com.ibm.display.PageUtils" %> <%@ page import="com.ibm.display.PageInfo" %> <% PageInfo pageInfo = (PageInfo)session.getAttribute("PAGE_DATA") %> <HTML> <HEAD> <TITLE> <%=pageInfo.getTitle()%> </TITLE> </HEAD> <BODY> <!-- Other HTML content --> </BODY> </HTML> |
根據最初的原則判斷,JSP 技術（至少在其說明的設計中）可以滿足表示技術的基本原則,正如上面概況的一樣：內容與表示分離.
代碼和標記
JSP 技術特性列表上的第二項可能會出現一些問題.JSP 代碼可以讓您將 Java 代碼直接插入到標記頁面.在開發 JSP 規範時,Microsoft Active Server Pages （ASP） 大獲成功,因此 Sun 與 Microsoft 之間的競爭空前激烈.這導致了這個決策的產生.JavaServer Pages 的名稱與 Active Server Pages 類似並非偶然.並且對眾多 API 特性的模仿也是蓄意而為.因此 JSP 創建者需要能夠將 Java 代碼添加到他們的標記中.
為了演示將 Java 代碼加入到標記中,清單 4 中的 JSP 代碼片段根據需要動態地添加行,以表示 actors 的 Vector 中的每一項.
| <%@ page import="com.ibm.display.PageUtils" %> <%@ page import="com.ibm.display.PageInfo" %> <%@ page import="com.ibm.people.Actor" %> <%@ page import="java.util.Iterator" %> <%@ page import="java.util.Vector" %> <% PageInfo pageInfo = (PageInfo)session.getAttribute("PAGE_DATA") Vector actors = pageInfo.getActors() %> <HTML> <HEAD> <TITLE> <%=pageInfo.getTitle()%> </TITLE> </HEAD> <BODY> <H2 ALIGN="center">Search Results: Actors</H2> <CENTER> <HR width="85%"> <TABLE width="50%" CELLPADDING="3" CELLSPACING="3" border="1" bgcolor="#FFFFCC"> <% for (Iterator i = actors.iterator(); i.hasNext()) { Actor actor = (Actor)i.next(); %> <TR BGCOLOR="#FFCCCC"> <TH width="50%" ALIGN="center"> <%=actor.getLastName()%> </TH> <TH width="50%" ALIGN="center"> <%=actor.getFirstName()%> </TH> </TR> <% } %> </TABLE> </CENTER> </BODY> </HTML> |
注意,目前為止,我僅僅介紹了 JSP 技術的最初設計目標；在下一節介紹 JSP 技術存在的問題之後,我將對這個目標作出自己的論斷.不過,您可能已經開始有點好奇,將代碼嵌入到 JSP 頁面中似乎與 JSP 技術的首要目標（分離內容和表示）有所衝突.實際上,我還沒有就此展開論述.
設計師和開發人員
JSP 技術的最終（也是值得稱讚）的目標是,它嘗試在應用程序開發過程中形成清晰定義的角色.通過在表面上分離內容和表示,JSP 技術能夠更加清晰地區分設計師和開發人員角色.設計師使用標準的 HTML、WML 或其他合適的語言創建標記,而開發人員編寫代碼.當然,如今很多設計師學習了 JavaScript 語言,因此,這些設計師開始學習 JSP 編碼也不是什麼令人吃驚的事情.通常,設計師並不會單純地創建純標記,他們會編寫一個完整的 JSP 頁面並將其交給開發人員.然後經過頻繁的修改,開發人員再將 JSP 頁面作為完整應用程序的前端使用.但是,這裡的關鍵問題是仍然有很多設計師沒有 學習 JSP 編碼,他們也必須能夠在這種環境下工作.
出現的問題
我剛剛介紹了一種良好的表示技術應該提供的功能,以及 JSP 技術嘗試解決的具體問題.現在,我將轉入正題：JSP 技術雖然建立在良好理念的基礎之上,但是卻出現了一些問題.在選擇 JSP 編寫您的應用程序之前（您可能仍然會這樣做）,至少應該注意一些容易出現的問題.
您還需要注意經常被忽略的 J2EE 編程平台：僅僅平台附帶了 API 並不意味著一定要使用它.和這種想法同樣可笑的是,很多開發人員在使用 JSP、EJB 或 JMS API 時,都在想如果不使用這些 API 的話,他們的應用程序就不是真正的 「J2EE 應用程序」 了.實際上,平台提供的 API 遠遠超過大多數應用程序的需要.如果您不能使用或對 JSP 技術還持有懷疑態度,那麼可以不使用它！在選擇 JSP 編寫應用程序之前,仔細研究它的優點和 缺點.讓我們看看其中一些缺點.
可移植性和語言鎖定
JSP 技術將您鎖定到某種特定的語言.這一點不應該給予太多的關注.至少在我看來,Java 技術是企業應用程序的惟一 選擇.在這個領域,根本不存在可以獨立於語言的解決方案.當然,在這個時候,我沒有把 Microsoft .NET 平台牽涉進來.只有時間可以告訴我們這個平台是否可以真正獨立於語言（我很懷疑這一點）.
然而,選擇 JSP 技術將強制您使用 Java 語言,至少對於內容和表示是這樣的.儘管 CORBA 可以用於業務邏輯,JSP 編碼要求必須熟悉 servlet 和核心 Java 語言.很多開發人員通過 J2EE 平台接觸 JSP 編碼,因此這通常算不成問題.
混合和獨立
在本篇文章中,我始終圍繞分離內容和表示這一概念.您可能對此已經感到不耐煩,那麼現在讓我們看看 JSP 究竟能不能實現這個目標.正如我們之前討論的一樣,JSP 宣稱 一直致力於實現內容和表示分離,那麼我們可以因此認為它實現了目標,是嗎？未必如此.
內容和表示之間的界限變得模糊
JSP 允許將 Java 代碼插入到標記語言頁面中,這個非常危險的特性允許將內容混合到表示中.更糟糕的是,業務邏輯通常會進入到 JSP 頁面中,如清單 5 所示.
| <%@ page import="com.ibm.display.PageUtils" %> <%@ page import="com.ibm.display.PageInfo" %> <%@ page import="com.ibm.logic.AdminUtils" %> <%@ page import="com.ibm.people.Actor" %> <%@ page import="java.util.Iterator" %> <%@ page import="java.util.Vector" %> <% PageInfo pageInfo = (PageInfo)session.getAttribute("PAGE_DATA") %> <HTML> <HEAD> <TITLE> <%=pageInfo.getTitle()%> </TITLE> </HEAD> <BODY> <H2 ALIGN="center">Search Results: Actors</H2> <CENTER> <HR width="85%"> <TABLE width="50%" CELLPADDING="3" CELLSPACING="3" border="1" BGCOLOR="#FFFFCC"> <% // Based on user's permissions, perform search differently (business logic!) Vector actors = pageInfo.getActors() if (pageInfo.getUserInfo().hasPermission("ADMINISTRATOR")) { actors = AdminUtils.getActors(pageInfo.getSearchCriteria()); } else { actors = pageInfo.getActors(); } for (Iterator i = actors.iterator(); i.hasNext()) { Actor actor = (Actor)i.next(); %> <TR BGCOLOR="#FFCCCC"> <TH width="50%" ALIGN="center"> <%=actor.getLastName()%> </TH> <TH width="50%" ALIGN="center"> <%=actor.getFirstName()%> </TH> </TR> <% } %> </TABLE> </CENTER> </BODY> </HTML> |
JSP 的擁護者會很快告訴您 JSP 標記庫 可以幫助您避免這個問題.標記庫允許將自定義標記（例如 <AUTHORS />）添加到 JSP 頁面,然後在運行時在標記庫內將其解析為代碼片段.
使用自定義標記和相關的標記庫允許把以上示例轉換為清單 6 所示的內容.
| <CENTER> <TABLE width="50%" CELLPADDING="3" CELLSPACING="3" border="1" 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 規範的當前版本為 1.1,它允許使用 scriptlets,因此在未來幾年內 JSP 頁面內都會支持這個特性.在深入探究 JSP 編碼之前,請注意,在其強調的完全分離內容和表示的理念和實際實現之間存在一個很大的缺口,它充其量只是假裝分離了用戶界面和驅動應用程序的代碼.
單處理和多任務處理
如前所述,理想狀態下,設計師應該能夠執行單獨處理,只關注圖形設計,而開發人員應該能夠將注意力集中在編程上.因此,設計師可以在將頁面轉換為適合應用程序的格式后,再對其進行處理.對於 JSP 頁面來說,將頁面轉換為適合應用程序的格式就是指向頁面導入 JavaBeans、插入內聯編碼並添加自定義標記庫.問題是有些設計師使用的是 HTML 編輯器,比如 HoTMetaL、Macromedia Dreamweaver 或 FrontPage,這些編輯器無法識別代碼 scriptlets 或標記庫,這意味著設計師實際上只收到了頁面的一部分.想象一下,標記庫或代碼片段只生成了表的若干行,或是頁面中其他格式化的細節,這是多麼麻煩的事情.設計師使用了不兼容的 HTML 編輯器,無法看到這些元素的外觀.在開發人員完成編碼后,設計師不能輕鬆地對頁面進行修改,這時,不僅沒有清晰地劃分角色,JSP 編碼實際上將這兩種角色合二為一：開發人員必須執行多個任務,必須擔當開發人員、設計師以及其他角色.
如果您仍然對此表示懷疑,那麼請下載 J2EE 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 （W3C） 規範,目前正在取代 HTML 4.0.XHTML 在實現格式良好的 XML 文檔方面定義了 HTML 標記集.例如,<br> 標記必須被轉換為 <br/> 才能確保 XML 兼容性（如果這個例子沒有解釋清楚的話,可以查閱 參考資料 列出的 XML 規範,以及關於 XHTML 的 developerWorks 文章）.同樣的規則適用於圖像標記,並且在 XHTML 1.1（即將到來）中,大部分字體屬性和其他樣式被移入到 CSS 樣式表中.另外,大多數標準 HTML 文檔可以輕鬆地轉換為 XHTML 1.0,這意味著可以使用任何與 XML 兼容的解析器讀取,例如 Apache Xerces,並且可以作為 XML 進行處理.
您會問 「這有什麼關係呢？」.答案是關係重大. XML 正在快速成為一個在應用程序之間和應用程序內部進行通信的全球標準.使用 XML 格式傳遞書籍,可以讓任何使用基本 XML 數據綁定功能的應用程序輕鬆地使用您的應用程序的數據.想象一下,通過將您的數據遷移到 XML 格式,您就可以與信用卡公司進行網上交易！多數情況下,您的數據表示還需要與其他公司進行交互.最常見的情況是門戶應用程序,它接受來自各種提供者的內容（例如,天氣信息、股票報價和新聞）,通常附帶有提供者的標記.然而,由於 JSP 頁面將代碼和自定義標記庫相混合,因此無法在這種環境下良好地工作.
JSP 頁面很少具有格式良好的 XML 文檔,並且不重視是否符合 XHTML,而 XHTML 這種標記語言並不允許使用各種 JSP 自定義標記庫.然而,更重要的是,插入到 JSP 頁面的代碼片段並不屬於任何標記形式,因此當另一個應用程序處理它們時,將產生解析器載入錯誤.
在您提出質疑之前,讓我們先了解一下整個情況.如果應用程序允許 JSP 頁面由初始客戶機處理,結果將產生純 HTML（或 WML、VoXML 等）.然而,大多數請求這個數據的應用程序使用了一定程度的緩存,網路往返開銷很昂貴.在這些情況下,緩存過的頁面將返回過時的數據.因此,您可能更願意返回與 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 技術看作是眾多其他表示技術的替代品.現在,您可能對整個J2EE編程模型也產生了一點懷疑.如果您希望進一步研究平台選擇,那麼可以在 Apache Cocoon、Enhydra 和各種模板引擎中尋找 JSP 技術的替代選擇.
,請記住,本文並不是建議您使用JSP或避免使用它,儘管表面上像是這樣.我的目的是鼓勵您對任何技術進行詳細的分析,確保它是正確的選擇.就像編程模型一樣,有時它們是合適的,然而有些時候它們並不適合.多進行一些比較,找到最適合自己的技術並作出明智的決定,而不是倉促地決定.
[火星人 ] Web開發須知 JSP技術優缺點詳解已經有933次圍觀
