XML和J2EE的组合技术3

<!-- 引入我们的类 -->
<%@ page import="jaf.xml.*" %>
<center><H3>Media Assets for Lecture 14:</H3></center>
<!-- 加载我们自定义的标记库 -->
<%@ taglib uri="http://javaschool.org/taglib" prefix="media" %>
<!-- 从一个先前定义的位置装载资源 -->
<media:load url="http://javaschool.org/jaf/E162/lecture14-assets.xml"
collectionName="assets" cursorName="asset" />
<table border=0>

      使用自定义标记的最大好处是使我们的程序代码集中在一个地方（对Java技术而言，一般是指在“类”中），易于管理。这样可以将程序中对象层同界面层的集成关系定义得很清晰，修改代码所造成的影响是可以预测和管理的。

      直接将XML数据转换成Web显示内容的另一种方法是使用XSL和XSLT。在这种方案中，将XML数据映射成HTML（或WML等）的逻辑由XSL样式表（XSL StyleSheet）来定义。样式表描述了每个特定XML数据实体应该怎样转换成界面数据实体（如HTML表格、内联标记等）。在JSP架构中，XSL转换只能应用于特定的XML数据源，最理想的是采用一套自定义的JSP标记并引用某个XSLT处理程序。这方面的典型示例请参考java.sun.com中关于XML同JSP构架集成的白皮书。

      同前面那个JSP自定义标记加XML解析器组件的方案相比，XSLT方案的伸缩性要好一些，而且具有更好的可管理性。在这种情形下，我们的转换逻辑是编写在一个XSL样式表中，而不是在Java代码中。这意味着当需要修改界面时，大多数情况下只是编辑样式表或者HTML，代码不受影响。不过在决定选用何种方案之前，还是要根据实际状况仔细权衡。如果选用XSLT方案，那么就得有人负责维护这些XSL样式表（要么是负责界面的人，要么是编写程序的人）。XSLT既像内容，又像程序，因此双方都不能把责任推给对方，结果大家可能都被这不伦不类的XSLT弄得矛盾百出。从这点上考虑，采用自定义标记并由界面开发者将其嵌入表示层的方法似乎更有吸引力，因为这样软件工程师只考虑Java代码，而内容工程师也只操心内容标记。

      Java servlet过滤器是J2EE 1.3版在其Web层最新发布的一种Web组件。当Sevelet将请求写入某个资源或者从某个资源中读取回答信息时，过滤器可以非常方便地转换其中的头信息和内容信息。这里所说的资源可以是一个Java servlet、一个JSP页面，甚至一个静态Web页。过滤器的确很“酷”，因为它允许开发人员从转换内容的代码中分离出生成内容的那部分代码，并加以重用。当需要通过XSLT方式将XML数据转换到不同的XML应用目标时，Java servlet过滤器尤其有用。

      在J2EE应用程序中使用Java servlet过滤器转换其输出，以便兼容任何类型客户端的前景呼之欲出。servlet过滤器能够侦测到来自使用WAP协议（无线应用协议）的移动客户端的呼叫，并且将答复内容转换成WML（无线标记语言）格式。servlet过滤器也能检测到来自iMode无线客户的呼叫，并将其转变成cHTML（紧凑HTML）格式。当然，servlet过滤器也能够分辨出传统的HTML浏览器客户的请求，并用正确的格式进行回复。

      在J2EE 1.2.1规范中，XML“集成”仅指组件或应用程序的XML格式的部署描述。在J2EE 1.3规范中，对XML的支持被扩展为要求具备SAX 2和DOM 2解析器，以及在兼容J2EE的服务器平台上提供XSLT转换处理程序。您可以毋庸置疑地相信，将来在J2EE架构中还会集成进更多的XML特性，因为J2EE规范的定义者们会认真倾听开发者社区中对在企业级应用中使用更多XML的渴求呼声。例如，JSR（Java定义请求）处理小组中与JAXM规范相关的部分（JSR 000067）承诺在J2EE后续规范中集成进JAXM。可以预见，在JSP架构、EJB和JDBC规范中均会有类似的变化。J2EE平台中上述组件的变革，将使Java技术开发者目前用的XML更为规范。