級別： 初級
Brett McLaughlin , 作家/編輯, O'Reilly Media
2008 年 11 月 17 日
作為一名資深的 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 技術是 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 ActiveServer 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、MacromediaDreamweaver 或 FrontPage，這些編輯器無法識別代碼 scriptlets或標記庫，這意味著設計師實際上只收到了頁面的一部分。想象一下，標記庫或代碼片段只生成了表的若干行，或是頁面中其他格式化的細節，這是多么麻煩的事情。設計師使用了不兼容的 HTML編輯器，無法看到這些元素的外觀。在開發人員完成編碼后，設計師不能輕松地對頁面進行修改，這時，不僅沒有清晰地劃分角色，JSP編碼實際上將這兩種角色合二為一：開發人員必須執行多個任務，必須擔當開發人員、設計師以及其他角色。
如果您仍然對此表示懷疑，那么請下載 J2EE Reference Implementation 并將其中一個附帶的 JSP 頁面加載到一個WYSIWYG HTML 編輯器，例如 Dreamweaver。頁面立即被一些黃色區域填充，告訴您頁面中包含的所有 “錯誤”標記。當然，黃色內容來自于 JSP 標記和代碼，而不是頁面出現了什么真正的錯誤。
迄今為止，尚未出現支持 JSP功能的 WYSIWYG 編輯器，我也沒有聽說過任何與此相關的項目。盡管模板引擎也具有相同的問題，但是很多基于 Java的解決方案，例如我最喜歡的Enhydra，都允許您將標記頁面作為輸入提供給表示技術。在這種情況下，設計師可以根據需要頻繁地進行修改，并重新提供標記頁面。運行表示技術的引擎或編譯程序將標記頁面轉換為適當的格式，并且不需要修改任何代碼（典型情況下）。最終獲得了理想的結果：設計師和開發人員各司其職。
因此，要注意 JSP 技術作出的承諾和它實際交付的實現。在實際中，要在一個 JSP 技術驅動的環境下發揮功效，必須讓開發人員處理大部分標記，或至少讓設計師學習一些 JSP 編碼。
JSP 技術最嚴重的缺陷之一（也是經常被忽視的一個缺陷）就是它與 XML 不兼容。更確切地說，并且特別針對 HTML 領域，JSP頁面不要求具備 XHTML 兼容性。XHTML 是一個 World Wide Web Consortium (W3C) 規范，目前正在取代HTML 4.0。XHTML 在實現格式良好的 XML 文檔方面定義了 HTML 標記集。例如，
<br>
標記必須被轉換為
<br/>
才能確保 XML 兼容性（如果這個例子沒有解釋清楚的話，可以查閱
參考資料
列出的 XML 規范，以及關于 XHTML 的 developerWorks 文章）。同樣的規則適用于圖像標記，并且在 XHTML1.1（即將到來）中，大部分字體屬性和其他樣式被移入到 CSS 樣式表中。另外，大多數標準 HTML 文檔可以輕松地轉換為 XHTML1.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或避免使用它，盡管表面上像是這樣。我的目的是鼓勵您對任何技術進行詳細的分析，確保它是正確的選擇。就像編程模型一樣，有時它們是合適的，然而有些時候它們并不適合。多進行一些比較，找到最適合自己的技術并作出明智的決定，而不是倉促地決定。
祝您愉快，我們網上見！
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
