JSP 技术 -- 是友还是敌？
批判性地看待一种可行的表示技术： JavaServerPages servlet 技术
Brett McLaughlin
Lutris Technologies 公司的 enhydra 战略家
2000 年 10 月
作为一名 Java 技术老手和新的 enhydra 拥护者，作者力劝开发人员在选择设计 Web 应用程序的途径时，考虑一下 JavaServerPages (JSP) servlet 以外的其他方法。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 显示，而这些 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、或者已变得面目全非了。
通常，设计人员必须在原始页上进行修改，并再次把此页交给开发人员。开发人员必须把此页再次转化为表示技术所使用的特定格式。否则，设计人员就必须学会一种脚本语言，或至少懂得此页中的哪些源代码区域是禁止入内的。当然，这是一种容易出错的、非常危险的方法。一旦您确定下来以一种表示技术支持内容和表示之间的明确分离，您就应确保改变表示所需的修改工作量限定在最小。
