JSP 技术 -- 是友还是敌？
批判性地看待一种可行的表示技术： JavaServerPages servlet 技术
Brett McLaughlin
Lutris Technologies 公司的 Enhydra 战略家
2000 年 10 月
内容： 历史点滴 前提 隔离与集成 编写与修改 JSP 的承诺 内容与表示 设计人员与开发人员 问题 单一处理与多任务 小结 参考资料 作者简介
表示技术设计用来将平淡的拉丁文原始 Web 内容转化为包装在有吸引力的表示层中的内容。JavaServer Pages (JSP) 技术，作为 Sun 公司的表示模型和 J2EE 平台的一部分，受到了极大关注。使用 JSP 技术有利有弊，Web 开发人员应知晓这些利弊 -- 懂得他们不必拘泥于这一技术。实际上，近来出现了许多表示技术。本文以表示技术所要解决的问题为开端，然后考察 JSP 模型的特有优势和弱点。最后，介绍几个可以代替 Sun 的表示技术的可行方案。
历史点滴
在深入解释表示技术之前，介绍一些导致此技术产生的详细背景资料很有帮助。仅仅在 10 年前，瘦客户机还是一个很新的术语。那时我们还生活在台式机应用程序的世界中，使用低级的 286 微处理器，眯着眼睛看 14 英寸的显示器。但是现在时代不同了，朋友！现在，我的台式机除了运行 Web 浏览器之外什么也不干。我们使用 Sun、IBM、HP、Compaq 和其他公司的服务器来运行计算、业务逻辑和内容。那个小显示器呢？它已被又大又漂亮的 21 英寸和 25 英寸等离子体平面显示器所取代。为什么呢？因为这样我们就可以观看错综复杂的 HTML 显示，而这些 HTML 显示是强大的应用程序的前端。单调沉闷的界面已不能满足要求；现在，我们希望看到华丽的图形、移动的图像、色彩协调的表示，不管哪个房间看上去都那么漂亮，并且能够快速显示出来。
前提
十年后的今天，作为雏形的 Windows 应用程序已经成为历史，我们仍面临着表示方法上的巨大转变。悲惨的 Visual Basic 和 C 程序员发现，他们现在只能编写后端系统或仅用于 Windows 的应用程序，或者已在自己的工具箱中添加了能提供 Web 功能的语言，例如 Java 语言。不支持四分之三以上 ML 语言（如 HTML、XML 和 WML）的应用程序即使不被认为是完全失败的，也会被认为是很低劣的。当然，这说明我们都很注重很容易地开发 Web 表示层的能力。
结果是，使用新的因特网，以及我们熟悉的所有语言（Java、C、Perl、Pascal、 Ada 以及其他语言）都不像我们所希望的那么容易。当将每个人都使用的编程语言用于后端程序并生成适用于客户机的标记语言时，会出现一大量的问题。随着浏览器提供更多的选项（例如 DHTML 和 JavaScript 编码）、Web 领域图形艺术人才的增加、以及能够使用标准 HTML 生成复杂界面的工具的出现，对别具一格的用户界面的需求比我们开发这些应用程序前端的能力增长得还要快。这就导致了表示技术的兴起。
表示技术设计用来执行一项任务：将内容（即不带显示详细信息的数据）转换为表示 -- 即您在电话、掌上电脑或 Web 浏览器中看到的各种用户界面。这些表示技术声称能够解决哪些问题？让我们来看一下。
隔离与集成
表示技术的最基本目的是使得内容和表示可以分离开来。换言之，业务逻辑单元（可能用 C 或 Java 语言编写）不必以表示特定的方式生成代码。数据或者内容以原始形式返回，不带任何格式。之后，表示技术为这些内容添加格式或表示。结果是，数据被图形、格式、颜色和徽标环绕包围起来。
请看清单 1 和清单 2 中的示例，看一下原始内容和结合了表示技术的内容之间的区别。
清单 1 显示的是原始内容，除了数据外别无他物，可以通过多种方式使用。
清单 1. 只包含数据的原始内容
Russell Crowe Tom Hanks Meg Ryan Mary Stuart Masterson Alec Baldwin Ashley Judd Keanu Reeves
清单 2 就比上一个清单复杂多了，它显示的是相同的数据，但这些数据包装在表示技术中，并且随时可以在支持 HTML 的浏览器中显示。
清单 2. 用表示包装的数据
<HTML> <HEAD> <TITLE>搜索结果：演员</TITLE> </HEAD> <BODY> <H2 ALIGN="center">搜索结果：演员</H2> <CENTER> <HR WIDTH="85%"> <TABLE WIDTH="50%" CELLPADDING="3" CELLSPACING="3" BORDER="1" BGCOLOR="#FFFFCC"> <TR BGCOLOR="#FFCCCC"> <TH WIDTH="50%" ALIGN="center">姓</TH> <TH WIDTH="50%" ALIGN="center">名</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 中的内容则专用于在浏览器中显示。从清单 2 中提取数据，或处理它用于其他目的，就需要有一些技巧。
这一基本区别 -- 将表示和内容分开而不是集成在一起的处理(至少在用户不需要这些信息时是这样), 是表示技术（包括 JSP 技术）的前提。进一步说，没有达到这一基本目标的表示技术就没有真正实现设计的最初目的。
编写与修改
除了将内容和表示分离开来以外，衡量表示技术是否有用的另外一个因素则是它所免除的修改工作量。表示和内容的分离加大了内容开发人员的角色差别。程序员可将注意力集中在前面示例中的原始内容上，图形艺术家或网站管理员则可将精力放在表示上。但是，在把艺术家设计的表示或标记取出并加入到程序员编制的内容中时，还会出现一些角色交迭。
在最简单的情况下，艺术家提供标记，开发人员提供代码并将标记插入表示技术中。然后，应用程序“启动”，内容会魔术般地变成一个用户界面。当然，我们都知道，开发工作通常不会仅止于此。下一步是修订和更改界面，并编制新的业务规则，这正是检验表示技术灵活性的地方。虽然更新输入到表示层中的原始数据通常并不难，但是图形艺术家就很难对他们的原始作品进行编辑。对表示层的更改是很常见的（我们都饱受过市场部门改这改那之苦）。所以，现在出现了这样一个问题：设计人员应该从何处入手来更改他们的工作？是修改他们交给开发人员的原始标记语言页吗？可能不是。因为最可能的是，此页很可能已插入定制标记或代码（JSP 页、模板引擎）、转化为 Java servlet、或者已变得面目全非了。
通常，设计人员必须在原始页上进行修改，并再次把此页交给开发人员。开发人员必须把此页再次转化为表示技术所使用的特定格式。否则，设计人员就必须学会一种脚本语言，或至少懂得此页中的哪些源代码区域是禁止入内的。当然，这是一种容易出错的、非常危险的方法。一旦您确定下来以一种表示技术支持内容和表示之间的明确分离，您就应确保改变表示所需的修改工作量限定在最小。
JSP 技术的承诺
现在，我们来讨论 JSP 编码的具体内容。JSP 技术承诺为设计人员和开发人员提供他们所需的最合适的表示技术。JSP 技术是 J2EE 平台的一部分，显示了 Sun 公司所能给予 Java 产品的最强大支持。为了使您对此解决方案的流行程度有一个概念，您可以试着在 amazon.com 上搜索一下“JSP”，您会发现，论述 JSP 的书籍比论述其他任何一种 Java API 的书籍都要多。在我深入讨论 JSP 技术存在的特定问题之前，您需要对它承诺的功能有一个清楚的了解。
内容与表示
首先，JSP 技术是用来分离内容和表示的，这一点最早出现在 Sun 对于 JSP 公布的一系列目标中。实际上，JSP 的设计直接针对开发人员的抱怨，这些开发人员对于在 servlet 代码中反复键入 out.println("<HTML><HEAD><TITLE>" + pageInfo.getTitle() + "</TITLE></HEAD>") 感到厌烦。这种硬编码内容和运行时变量的混合对 servlet 开发人员造成了巨大的负担，也使开发人员在对表示层进行即便是最小的改动时也困难重重。
JSP 技术通过支持普通 HTML 页（以及稍后的 WML 或其他标记语言页）在运行时编译为 Java servlet，改变了这种情况。它实际上是模仿 out.println() 语句，而无须开发人员编写代码。同时还允许在页面中插入变量，直到运行时才解释这些变量。
清单 2 所示的 HTML 片段相对应的 JSP 页应与清单 3 中的示例相似。
清单 3. 一个使用表示技术包含数据的 JSP 页
<%@ 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> <!-- 其他 HTML 内容 --> </BODY> </HTML>
按这些初始原则判断，JSP 技术（至少在它的声明设计中）会满足表示技术的第一个原则，如上所述：即内容与表示的分离。
代码与标记
JSP 技术所列的第二个特性可能引起你的注意，那就是，JSP 编码允许直接向标记页中插入 Java 代码。为了理解作出这种决定的原因，我们回想一下制定 JSP 规范时的情况。Sun 与微软的竞争一直非常激烈，主要源于微软 Active Server Pages （ASP）的成功。JavaServer Pages 与 Active Server Pages 在名称上的相似并非巧合。而且模仿 ASP 的多种特性似乎亦是有意的。所以 JSP 的作者选择了在他们的标记中加入 Java 代码。
作为向标记中加入 Java 代码的一个例子，清单 4 中的 JSP 片段自动按需要添加行，以显示演员 Vector 中的每一项。
清单 4. 插入到标记语言页中的 Java 代码
<%@ 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">搜索结果：演员</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 平台的烟幕及其实际情况。只有时间会证明 Microsoft .NET 平台是否会发展成为一个真正独立于语言的产品。（我很怀疑。）
还有，选择 JSP 技术会强制您使用 Java 语言，至少对表示和内容而言是这样。虽然 CORBA 可用于业务逻辑，但进行 JSP 编码确实需要熟悉一些 servlet 以及核心的 Java 语言。由于许多开发人员都是从 J2EE 平台转向 JSP 编程，所以这点通常不是问题。
混合与独立
在全文中，我多次提到把内容和表示分离的想法。您也许已经听烦了，那么现在到了我们来确定 JSP 是否真的实现了这个目标的时候了。正像我已说过的那样，既然 JSP 声称是为这一分离目标而设计的，所以我们应该假定它实现了这个目标？对吗？未必。
模糊了内容与表示之间的界限
JSP 允许向标记语言页中插入 Java 代码，这一点相当危险，它甚至允许将内容混合到表示中。更糟的是，业务逻辑经常混入 JSP 页中，如清单 5 所示。
清单 5. 包含业务逻辑的 JSP 页
<%@ 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">搜索结果：演员</H2> <CENTER> <HR WIDTH="85%"> <TABLE WIDTH="50%" CELLPADDING="3" CELLSPACING="3" BORDER="1" BGCOLOR="#FFFFCC"> <% // 根据用户的权限，执行不同的搜索（业务逻辑!) 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 标记库可以帮助您避免这种问题。标记库允许向 JSP 页加入定制的标记（例如<AUTHORS />），这些标记在运行时解释为标记库中的代码片段。
使用定制标记和相关的标记库会使上面的示例变为清单 6 中的代码。
清单 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 语言优于 C，是因为它禁止这种坏习惯出现。但 JSP 在这种情况下，与 C 语言极为相似，它允许一些坏习惯。
对于 JSP 技术是否达到了它所宣称的目标, 还有一个测试标准，就是看它实际上是否能够达到目标。当然，以不可能达到的标准来要求 JSP 是不公平的。大多数模板引擎（例如 FreeMarker 和 WebMacro）有这种相同的内嵌代码功能，通常这些模板使用类似 Perl 的语言。但是，像 Enhydra 的 XMLC 这样的技术，不允许这种内嵌代码。这些技术使用一个纯标记语言页作为输入来代替，并生成 Java 方法。这种做法实质上是改变了程序流，而不是页面（JSP 技术）调用应用程序的逻辑，应用程序（Enhydra）使用方法来影响页面中的值。在 Enhydra 的特定情况下，XMLC 把页面转化为一个 DOM 树，并使用 DOM 的 HTML 绑定来允许页中“域”的更新。（关于 Enhydra XMLC 的详细信息，请参阅参考资料。）
在这一点上，JSP 比 XMLC 问题更严重。例如，虽然 JSP 技术能够实现它的目标，但是它只允许使用标记库。但是，Sun 规范中的总趋势是始终保持向后兼容，或至少保持相当长的一段时间。当前版本的 JSP 1.1 允许使用 scriptlet，所以估计 JSP 页包含代码这一情况还要维持几年。在深入探讨 JSP 编码前，请注意它实际提供了产品（它至多不过是用户界面和驱动应用程序的代码之间的伪分离）和它的目标（即完全分离内容和表示）之间仍有相当大的差距。
单一处理与多任务
如上讨论，理想情况下，设计人员应该只执行单一处理，即只进行图形设计工作，开发人员应该只注重于编码。这样，在一个页面转化为应用程序所使用的格式后，设计人员应能够修改它。在 JSP 页的情况下，这应该在导入 JavaBean、插入内嵌代码、在页中加入定制标记库之后。问题是有些设计人员使用 HTML 编辑器，如 HoTMetaL、Macromedia Dreamweaver 或 FrontPage，这些编辑器不能识别代码 scriptlet 或标记库，这意味着设计人员实际上只收到了部分页面。当标记库或代码段在页中产生表格行或其他格式的具体内容时，其困难程度可想而知。使用不兼容的 HTML 编辑器，设计人员无法看到那些元素是什么样子。当设计人员无法方便地修订开发人员编译后的页面时，JSP 编码不是把不同的角色区分开来，而是使这些角色合并在一起：开发人员必须能够完成多种任务，成为开发人员兼设计人员并承担其他角色。
这种重要特性没有使您信服吗？那么您可以下载 J2EE 参考实现，并把其中任意一个包含的 JSP 页调入所见即所得的 HTML 编辑器，如 Dreamweaver。这个页面立即充满黄色区域，使您知道包含在页面中的所有“非法”标记。当然，黄色区域是由 JSP 标记和代码造成的，不是页中的任何实际错误。
到目前为止，还没有出现任何能够支持 JSP 的所见即所得编辑器，我也没有听说有人正致力于开发这样的编辑器。模板引擎亦有这种相同的问题，许多基于 Java 的方案（例如我喜欢的 Enhydra），允许把标记页作为输入提交表示技术。在这种情况下，设计人员可以反复修改标记页，再把它们重新提交回去。运行表示技术的引擎或编译器可以将此页面转换为正确的格式，并且不需要改变代码（在通常情况下）。结果正是我们所希望的：设计人员就是设计人员，而开发人员就是开发人员。
所以，和 JSP 技术实际提供的功能相比较，我希望您一定要小心对待 JSP 技术提出的承诺。实际上，为了使应用程序在一个 JSP 技术驱动的环境下成功运行，您必须让您的开发人员处理大量标记，或者使设计人员至少学习一些 JSP 编程。
HTML 与 XML
JSP 技术的一个最严重的缺陷，也是最易被忽视的一点，就是它与 XML 不兼容。更准确的说，尤其是在 HTML 领域中，JSP 页不需要兼容 XHTML。XHTML 是一个万维网联盟 (W3C) 规范，它现在正取代 HTML 4.0。XHTML 按照一种结构完整的 XML 文档定义 HTML 标记集。例如 <br> 标记必须转换为 < br/>，以确保遵守 XML 规定。（如果您觉得这一点没有阐明清楚，可以查阅 XML 规范和 developerWorks 关于 XHTML 的文章，它们在列在参考资料中。）图像标记也有类似的规则，在 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 代码 scriptlet 和标记库。
检验一下：有其他表示技术能够完成这个任务吗？答案是肯定的。在此领域的绝对领先者是 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。我无意鼓励您深入到任何技术的深层探究它是否符合您的要求。编程模型就像是例子，有时行得通，有时行不通。三思而后行，找到最适合您的方案再做决定，这总比草率做决定要好。
玩得开心，网上见！
参考资料 参阅当前的 JSP 规范，以获得全部内容。 进一步查看 JSP 1.2 中的新内容。 担心 XML 的兼容性吗? 您可以阅读规范以及 Molly Holzschlag 的文章 article for developerWorks on getting up to speed，以获得 XHTML 的详细信息。 在 W3C Style Center 上获得样式文档的 XML 视图。 需要知道比提供 JSP 更多功能的 J2EE 方案吗？它也是开放源代码的吗？请阅读今天的 Enhydra。 解放您的思想，看一下 Apache Cocoon，它是使用 XSLT 处理动态目录的另一个开放源代码的替代方案。 如果您不介意跳出 Java，模板引擎可以解救您！两个值得一看的站点是 WebMacro 和 FreeMarker。
作者简介
Brett McLaughlin 是 Lutris Technologies 公司的 Enhydra 战略家，专门研究分布式系统体系。他是 Java and XML (O'Reilly) 的作者；从事 Java servlet、Enterprise JavaBeans 技术、XML 和企业对企业的应用程序的研究。最近与 Jason Hunter 起创建了 JDOM 项目，此项目为从 Java 应用程序操纵 XML 提供简单的 API。他还是 Apache Cocoon 项目、EJBoss EJB 服务器的活跃开发人员，并且是 Apache Turbin 项目的创始人之一。可以通过 [email protected] 与 Brett 联系。
本文地址：http://com.8s8s.com/it/it18520.htm