< ?xml version="1.0"?> 　　< %@ page contentType="application/xml" %> 　　< %@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> 　　< c:set var="cust" value="${requestScope.customer}"/> 　　< orderhistory username="${cust.username}"> 　　< c:forEach var="order" items="${cust.orders}"> 　　< order id="${order.id}" cost="${order.formattedCost}"> 　　< date>${order.date}< /date> 　　< items> 　　< c:forEach var="item" items="${order.items}"> 　　< item id="${item.id}"> 　　< name>< c:out value="${item.name}" escapeXml="true"/>< /name> 　　< price>${item.formattedPrice}< /price> 　　< /item> 　　< /c:forEach> 　　< /items> 　　< /order> 　　< /c:forEach> 　　< /orderhistory>

　　这个简洁的模板只输出订单历史视图需要的数据，不输出不相关的资料(例如商品说明)。创建产品搜索视图的定制XML应当同样简单，这个视图包含每个商品的完整说明和库存水平。

　　模板的问题

　　另一方面，现在我需要为每个不同视图创建一个新JSP，而不能仅仅把需要的对象图组织起来并序列化它。从设计的角度来说，许多人可能会有争议，认为这无论如何是件好事，因为这意味着正式地考虑服务器要生成的文档类型。而且，因为我现在要处理通用的模板环境，而不是特定于XML的API，所以确保标记匹配、元素和属性的顺序正确以及XML实体(例如<或&)正确转义就成了我的责任。JSP的核心out标记使后面这项工作变得很容易，但是不是所有的模板技术都提供了这样的机制。最后，没有方便的途径可以在服务器端根据方案检验生成的XML文档的正确性，但这毕竟不是要在生产环境中做的事，可以方便地在开发期间处理它。

　　不用XML的响应数据

　　迄今为止，我介绍的所有技术都用XML文档的形式生成服务器响应。但是，XML有一些问题。其中一个就是延迟。浏览器不能立即解析XML文档并生成DOM模型，所以这会降低某些Ajax组件需要的“迅捷”感，特别是在较慢的机器上解析大型文档的时候更是如此。“现场搜索”就是一个示例，在这种搜索中，当用户输入搜索术语时，就会从服务器提取搜索结果并显示给用户。对于现场搜索组件来说，迅速地响应输入是非常重要的，但是同时它还需要迅速而持续地解析服务器的响应。

　　延迟是一个重要的考虑因素，但是避免使用XML的最大原因是差劲的客户端DOM API。清单5显示了使用跨浏览器兼容的方式通过DOM得到某个值的时候，通常不得不面对的困难。