迄今为止，我介绍的所有技术都用 XML 文档的形式生成服务器响应。但是，XML 有一些问题。其中一个就是延迟。浏览器不能立即解析 XML 文档并生成 DOM 模型，所以这会降低某些 Ajax 组件需要的“迅捷”感，特别是在较慢的机器上解析大型文档的时候更是如此。“现场搜索”就是一个示例，在这种搜索中，当用户输入搜索术语时，就会从服务器提取搜索结果并显示给用户。对于现场搜索组件来说，迅速地响应输入是非常重要的，但是同时它还需要迅速而持续地解析服务器的响应。
延迟是一个重要的考虑因素，但是避免使用 XML 的最大原因是差劲的客户端 DOM API。清单 5 显示了使用跨浏览器兼容的方式通过 DOM 得到某个值的时候，通常不得不面对的困难。
清单 5. 在 JavaScript 中导航 XML 响应文档
// Find name of first item in customer's last order
var orderHistoryDoc = req.responseXML;
var orders = orderHistoryDoc.getElementsByTagName("order");
var lastOrder = orders[orders.length - 1];
var firstItem = lastOrder.getElementsByTagName("item")[0];
var itemNameElement = firstItem.firstChild;
var itemNameText = itemNameElement.firstChild.data;
|
当元素中间存在空白时，情况就变得更加复杂，因为每个元素的 firstChild 经常是个空白文本节点。现在有 JavaScript 库可以缓解处理 XML 文档的麻烦。这些库包括 Sarissa （请参阅 参考资料）和 Google-ajaXSLT，这两个库都把 XPath 功能添加到了大多数浏览器中。
但是，想想替代方案还是值得的。除了 responseXML 之外，XMLHttpRequest 对象还提供了名为 responseText 的属性，这个属性只是以字符串的方式提供服务器的响应体。
当服务器需要向客户机发送非常简单的值时，responseText 特别方便，它可以避免 XML 导致的带宽支出和处理支出。例如，简单的 true/false 响应可以由服务器以纯文本方式返回，可以是逗号分隔的简单的名称或数字列表。但是，一般来说，最好不要在同一个应用程序中把 XML 响应和纯文本响应混合使用；保持单一数据格式可以让代码抽象和重用更加简单。
responseText 与 XML 响应数据结合时也会有用。在只需要从响应文档中提取单一值的场景中，“欺骗性”地把 XML 当作文本字符串，而不把它当作结构化的文档对待，会更方便。例如，清单 6 显示了如何用正则表达式从顾客的订单历史中提取第一笔订单的日期。不过，这实际是种花招，一般不应当依赖 XML 文档的词汇表达。
清单 6. 用正则表达式处理 XMLHttpRequest 的 responseText 对象
var orderHistoryText = req.responseText;
var matches = orderHistoryText.match(/<date>(.*?)<\/date>/);
var date = matches[1];
|
在某些情况下，采用即时方式使用 responseText 会比较方便。但是，理想情况下，应当有种途径，可以用一种能够让 JavaScript 轻松导航、却没有 XML 处理支出的格式表示复杂的结构化数据。幸运的是，确实存在这样一种格式。
