JSP 标记库：着意设计的更好的可用性

　　JavaServer Pages（JSP）技术是用于开发 Web 应用的优秀体系结构，但它的最重要的实用技术之一 ― 定制标记库（custom tag library）― 却常常未被充分利用。标记库实用技术未被充分利用的主要原因不是技术上的，而是语言上的。标记库生产者和消费者说的不是相同的语言。JSP 专家和顾问 Noel J. Bergman 揭示了问题的本质并提供了一些可行的解决方案。

　　将底层内容模型与表示分离是件好事，这在 Web 应用开发人员中间得到了普遍的认同。在多数大型开发工程中，程序员负责实现后端，表示则留给一名或多名 Web 页面设计人员去做。这种分工确保了最终产品技术可靠、同时表示良好，但它肯定要求两个小组有效地沟通和合作。考虑到每个小组工作时所依赖的知识基础不同，而且关注的问题也极其不同，这可能是一个挑战。

　　在引入 JavaServer Pages（JSP）规范的版本 1.1 中的定制标记库之前，必须使用 JSP 脚本元素来在 JSP 页面内提供任意的定制功能性。显式地使用脚本元素违背了模型与表示相分离的原则。显式地使用脚本元素还要求，如果 Web 页面设计人员要做任何“从 JavaBean 组件中检索属性”之外的事情，他就要具有 Java 编程经验。这引起了人们对 JSP 页面内脚本元素的使用的广泛关注，这接着导致了人们进行替代解决方案的开发。

　　一个经典的解决方案是开发出了模型-视图-控制器（Model-View-Controller）类型的使用模型。在这种使用模型中，应用程序的智能部分放置在 servlet 和 bean 中，JSP 页面只负责检索内容并将它呈现出来。Jakarta Struts 就是这种模型的一个很好的示例。别的开发小组已经创建了诸如 Velocity 内容引擎或 Apache 的 Cocoon 工程这样的替代技术。

　　虽然这些解决方案各有千秋，但它们通常是非标准的，而且忽视了 JSP 技术的持续发展。我们将在本文着重讨论 JSP 技术中使用最不充分的实用技术之一：定制标记库。我的目标是改变您对定制标记库（更具体地说，是标记设计）的思考方式。我的讨论将从澄清关于 JSP 技术及其某些替代解决方案的一些误解开始，然后再转到中心论题上。

　　JSP 技术：误解和替代解决方案

　　关于 JSP 技术的常见误解有很多，其中一些误解通常已经过时，而且还吓走了潜在的用户。表 1 列出了一些最常见的误解。

　　表 1. JSP：误解

误解	真相
JSP 页面要求以脚本元素的形式对代码模型和表示进行混合。	正如我们将在下一部分讨论的那样，标记库证明了这种说法是错误的。
JSP 页面脚本编制实际上就是 Java 编程。	这只是部分正确的。自版本 1.0 以来，JSP 规范就已允许使用多种脚本语言。然而，这一功能并未得到广泛实现。IBM WebSphere 允许使用多种脚本语言，而且其底层技术是以开放源代码方式发布的（请参阅旁注 “替代解决方案的变通办法”）。此外，通过 JSP 标记库，Velocity 模板语言（Velocity template language）也是可用的。
JSP 页面不好，因为它允许进行脚本编制。	这一抱怨在最近对 JSP 规范的修改中得到了解决。JSP 规范的当前发行版为标记库引入了一个新的概念。标记库可以包含一个验证方法，以对任何要使用该标记库的 JSP 页面进行验证。 在 2001 年科罗拉多软件峰会（Colorado Software Summit 2001）上，Mark Kolb 演示了一个简单的标记库验证器，这个标记库验证器验证了 JSP 页面完全可以不要脚本（请参阅 参考资料）。

　　上面列出的每一种误解都曾经至少是部分正确的。不过，JSP 技术是 J2EE 规范的主要部分而且得到了广泛使用。因此，会有很多厂商通过各种努力发展 JSP 技术并使之成熟，以解决用户所关心的问题。这是使用标准技术、而不使用专门的解决方案的好处之一。

　　虽然如此，在负责部署 Web 应用的经理们中间还是顽固地存在一种常见的思想。由于不了解误解背后的真相，又被告知 JSP 技术混合了编程和表示，这些经理们的第一反应是说他们将寻求 JSP 的替代解决方案，例如 Velocity。所以问题就是，像 Velocity 之类的解决方案真的能够解决问题吗？

　　Velocity 文档叙述说，它“允许任何人使用这种简单但强大的模板语言来引用 Java 代码中定义的对象”，文档还叙述说“Velocity 模板语言（VTL）旨在提供一种最容易、最简单而且最干净的方式，将动态内容结合到 Web 页面。即便是只有一点点或完全没有编程经验的 Web 页面设计人员，也应该很快就能够用 VTL 来将动态内容集成到 Web 站点。”换句话说，Velocity 并未将编程从表示中除去；而是要求用户学习一种新的专门的脚本语言。由于 Velocity 要求 Web 页面设计人员学习 Velocity 模板语言，它未能消除“内容和表示混合”的问题。

　　Velocity 只是市面上众多模板引擎的一个例子，但是，市面上的多数模板引擎，如 Velocity，都要求具有一定的前端编程技能。

　　JSP 技术的另一个流行的替代解决方案是 Cocoon 工程。Cocoon 是一种讨人喜欢的技术，它使用 XML 作为它的源数据格式。XSLT 转换的作用是将 XML 内容转换成适合于用户代理的格式，例如，适合于浏览器的 HTML。Cocoon 有它自己的称为 XSP 的动态页面格式。XSP 是 JSP 的近亲，但它工作在 Cocoon 环境中。XSL 会广泛存在的原因是，没有一种很好的办法将来自 JSP 页面的 XML 输出通过 Cocoon 发送到浏览器。早期 servlet 容器中的 servlet 链接机制无法胜任这一工作。不过，现在 Sun 已经引入了一种新的 servlet 过滤器机制，这种机制完全有能力将来自任意的 servlet 的 XML 输出通过一系列过滤器发送出去。从这个角度看，对 XSP 的需要明显降低了，需要 Cocoon 工程来提供其 XSLT 转换引擎作为 servlet 过滤器也变得明确起来。

　　关键的是，JSP 技术正在不断发展，以满足它的用户的需求。这意味着对 JSP 技术的任何评估都必须考虑到对其最新规范的审慎评论。即使是几个月前的评论和社论也会因出现了新的发展而显得过时（请参阅 参考资料）。

　　PS:(替代解决方案的变通办法

　　和所有技术平台一样，JSP 的确也有