分类： Java
2009-06-16 17:54:59
注意，目前为止，我仅仅介绍了 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" %﹥使用自定义标记和相关的标记库允许把以上示例转换为清单 6 所示的内容。
在运行时，将执行标记的代码并把正确的结果插入到页面中。但是这并没有解决问题。反对 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 标记集。例如，标记必须被转换才能确保 XML 兼容性（如果这个例子没有解释清楚的话，可以查阅 参考资料 列出的 XML 规范，以及关于 XHTML 的 developerWorks 文章）。同样的规则适用于图像标记，并且在 XHTML 1.1（即将到来）中，大部分字体属性和其他样式被移入到 CSS 样式表中。另外，大多数标准 HTML 文档可以轻松地转换为 XHTML 1.0，这意味着可以使用任何与 XML 兼容的解析器读取，例如 apacheXerces，并且可以作为 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或避免使用它，尽管表面上像是这样。我的目的是鼓励您对任何技术进行详细的分析，确保它是正确的选 择。就像编程模型一样，有时它们是合适的，然而有些时候它们并不适合。多进行一些比较，找到最适合自己的技术并作出明智的决定，而不是仓促地决定。
