Ajax 客户机/服务器通信可以很巧妙
Brett McLaughlin (mailto:[email protected]?subject=在请求和响应中使用 [email protected]), 作家,编辑, O'Reilly Media Inc.
2006 年 12 月 21 日
在 本系列的上一篇文章 中,您看到了 Ajax 应用程序如何以 XML 格式化发往服务器的请求。还了解了为什么这在大多数情况下并不是一个好主意。这篇文章主要探讨在大多数情况下 确实是 好主意的一种做法:向客户机返回 XML 响应。
我其实并不喜欢写那种主要告诉您什么不应该 做的文章。很多时候,那都会是一篇非常愚蠢的文章。我要在前半篇文章中解释某些东西,然后在后半篇文章中说明使用您刚刚才学会的那种技术是一个多么糟糕的主意。在很大程度上,上一期文章正是这样一种情况(如果您错过了那一期文章,请查看 参考资料 中的链接),那篇文章教您如何将 XML 作为 Ajax 应用程序的请求数据格式使用。
但愿这篇文章能够弥补您花费在学习 XML 请求上的时间。在 Ajax 应用程序中,使用 XML 作为发送数据的格式的理由很少,但使服务器向 客户机回发 XML 的理由很多。因此,您在上一篇文章中学到的关于 XML 的知识最终将在这篇文章中体现出某些价值。
服务器(有时)不能响应太多的请求
在深入钻研从服务器获取 XML 响应的技术之前,您需要理解,为什么说使服务器发送 XML 来响应请求是一个好主意(以及这与客户机发送 XML 请求不同的原因所在)。
客户机以名称/值对发送请求
回忆一下上一篇文章,就会知道,在大多数情况下,客户机不需要使用 XML,因为他们会使用名称/值对发送请求。因此,您可能会发送一个这样的名称:name=jennifer
。只需简单地在连续的名称/值对之间添加一个 “与” 符号(&
),即可将其放在一起,就像这样:name=jennifer&job=president
。使用简单的文本和这些名称值对,客户机即可轻松向服务器请求多个值。很少需要用到 XML 提供的额外结构(及其带来的额外开销)。
实际上,需要向服务器发送 XML 的所有理由都差不多可以归入以下两个基本的类别中:
服务器无法(以一种标准方式)发送名称/值对
在您发送名称/值对时,Web 浏览器会发送请求,平台会响应该请求,并承载一个服务器程序,配合它将那些名称/值对转换成服务器程序可以轻松处理的数据。实际上,每一种服务器端技术 —— 从 Java™ servlet 到 PHP、再到 Perl、Ruby on Rails —— 都允许您调用多种方法来根据名称获取值。因此,获取 name
属性只是小事一桩。
这种情况并不会将我们引向另外一个方向。如果服务器使用字符串 name=jennifer&job=president
应答一个应用程序,客户机没有任何标准化的简便方法来将每个对拆分成名称和值。您必须手动解析所返回的数据。如果服务器返回一个由名称/值对构成的响应,这样的响应的解释难度与使用分号、竖线或其他任何非标准格式化字符相同。
|
对于您来说,这就意味没有任何简单的方法在响应中使用纯文本、使客户机以一种标准的方法获取并解释响应,至少在响应包含多个值时是如此。假设您的服务器只是要发回数字 42,那么纯文本是很好的选择。但如果服务器要一次性发回电视剧 Lost, Alias 和 Six Degrees 的近期收视率又该怎么办呢?尽管可以选择许多种方法来使用纯文本发送这一响应(清单 1 给出了一些示例),但没有一种是不需客户机进行某些处理的极其简单的方法,也没有一种是标准化的方法。
尽管不难找到拆分这些响应字符串的方法,但客户机将不得不根据分号、等号、竖线和与符号解析并拆分这些字符串。这不是编写使其他开发人员能够轻松理解和维护的健壮代码的方法。
进入 XML
意识到没有任何标准的方法可以使服务器使用名称/值对响应客户机之后,使用 XML 的原因也就显而易见了。向客户机发送数据时,名称/值对是非常好的选择,因为服务器和服务器端语言可以轻松解释名称/值对;向客户机返回数据时使用 XML 也是如此。在本系列前几期的文章中,您已经看到了利用 DOM 来解析 XML,在后续的文章中,还会看到 JSON 怎样提供了解析 XML 的另一种选择。在所有这一切之上,您可以将 XML 作为纯文本处理,并以这种方式获取其值。因此,有几种方法可从服务器获得 XML 响应,并使用较为标准的代码提取数据,在客户机中使用这些数据。
还有一个额外的好处,XML 非常易于理解。比如说,大多数编写程序的人都能理解 清单 2 中的数据。
在特定分号或撇号的含义方面,清单 2 中的代码没有任何隐晦之处。
从服务器接收 XML
由于本系列的重点在于 Ajax 应用模式的客户端,因此我不会深入探讨关于服务器端程序如何才能生成 XML 响应的细枝末节。但在您的客户机接收 XML 时,您需要了解一些特殊的考虑事项。
首先,您可使用两种基本的方式处理一个来自服务器的 XML 响应:
Document
对象表示。 其次,举例来说,假设有一个来自服务器的简单 XML 响应。清单 3 展示了与上面介绍的内容相同的收视率程序清单(实际上,是与 清单 2 相同的 XML,在这里再次给出只是为了使您便于查看)。我将在这部分的讨论中使用这段样本 XML。
将 XML 作为纯文本处理
处理 XML 的最简单的选择(至少就学习新的编程技术而言),就是用与处理服务器返回的其他文本片段相同的方法来处理它。换言之,基本上就是忽略数据格式,只关注服务器的响应。
在这种情况下,您要使用请求对象的 responseText
属性,就像在服务器向您发送非 XML 响应时一样(参见 清单 4)。
|
在这个代码片段中,updatePage()
是回调方法,request
是 XMLHttpRequest
对象。最终,您将得到把所有一切串联在一起的 XML 响应,位于 response
变量之中。如果输出此变量,您会得到类似于清单 5 的结果。(请注意,清单 5 中的代码在正常情况下应该是连续的一个代码行。这里采用多行形式是为了显示正常。)
这里,要注意的最重要的地方就是 XML 是作为整体运行的。在大多数情况下,服务器不会使用空格和回车来格式化 XML,而是将一切串联在一起,就像您在 清单 5 中看到的那样。当然,您的应用程序不会过于在意空格,所以这算不上什么问题,但确实会使代码阅读起来较为困难。
在这里,您可以使用 JavaScript split
函数来拆分此数据,并通过基本的字符串操作来获得元素的名称和值。毫无疑问,这是个令人头疼的过程,它无视于您花费了大量时间来阅读前几期文章中 DOM(Document Object Model)相关内容这一事实。因此,我要强调,您应该牢记:利用 responseText
,可以轻松使用和输出服务器的 XML 响应,但我不会为您展示太多的代码,在能够使用 DOM 时,您不应选择这种方法来获得 XML 数据,下面您会看到这一点。
将 XML 当成 XML
尽管可以 将服务器的 XML 格式的响应视同为其他任何文本响应来处理,但这样做没有很好的理由。首先,如果您一直忠实地阅读这个系列,那么您已经学会了如何使用 DOM 这种对 JavaScript 友好的 API 来操纵 XML。还有更好的事情,JavaScript 和 XMLHttpRequest
对象提供了一个属性,它能完美地获取服务器的 XML 响应,并且是以 DOM Document
对象的形式来获取它。
清单 6 给出了一个实例。这段代码与 清单 4 类似,但没有使用 responseText
属性,回调函数使用的是 responseXML
属性。该属性在 XMLHttpRequest
上可用,它以 DOM 文档的格式返回服务器的响应。
现在您有了一个 DOM Document
,可以像处理其他任何 XML 一样处理它。例如,随后可能要获取所有 show
元素,如 清单 7 所示。
如果您熟悉 DOM,从这儿开始,看起来就应该有几分熟悉了。您可以使用您所了解的全部 DOM 方法,轻松操纵从服务器处接收到的 XML。
当然,您也可以混用普通的 JavaScript 代码。例如,可以遍历所有 show
元素,如 清单 8 所示。
通过这段非常简单的代码,您正是将 XML 响应作为 XML 而不是无格式的纯文本进行了处理,还使用了一点 DOM 和简单的 JavaScript 来处理服务器响应。更重要的是,您使用了标准化的格式 —— XML,而不是以逗号分隔的值或以竖线分隔的名称/值对。换句话说,您将 XML 用在了最适合它的地方,避免了在不适合的地方使用它(比如说向服务器发送请求时)。
服务器端的 XML:一个简单的示例
我不会谈太多有关如何在服务器上生成 XML 的内容,但花点儿时间看一个简单的示例是值得的,我没有给出过多的注释,以便您自行思考如何应对这样的场景。清单 9 展示了一个简单的 PHP 脚本,假设有一个异步客户机发出了请求,该脚本将输出 XML 来应答此请求。
这是一种强力(brute force)的方法,PHP 脚本实际上是手动生成 XML 输出。您可以找到许多工具包和 API,用于 PHP 和其他众多允许您生成 XML 响应的服务器端语言。无论您的情况如何,这都至少能让您了解生成 XML 并以之应答请求的服务器端脚本看上去是什么样子。
您应能够使用您偏爱的服务器端语言以类似的方式输出 XML。IBM developerWorks 上有许多文章可以帮助您了解如何使用您喜爱的服务器端语言生成 XML 文档(相关链接请参见 参考资料)。
解释 XML 的其他可选方法
除将 XML 作为无格式文本处理或使用 DOM 处理之外,还有一种非常流行的选择很重要,值得一提。那就是 JSON(JavaScript Object Notation),这是一种绑定在 JavaScript 内的自由文本格式。这篇文章中没有足够的空间介绍 JSON,在后续文章中将探讨相关内容;只要提起 XML 和 Ajax 应用程序,您就很可能会听到有人谈论 JSON,因此现在我将告诉您,您的工作伙伴们在谈论的究竟是什么。
大体上,可以用 JSON 做的事,用 DOM 都可以完成,反之亦然;选择主要取决于偏好,当然也要为特定的应用程序选择正确的方法。就现在而言,您应坚持使用 DOM,在接收服务器响应的过程中熟悉 DOM。我将占用几期文章的篇幅、用大量的时间去探讨 JSON,之后您就可以随意选择在下一个应用程序中使用那种技术了。请继续关注本系列:后续文章中将介绍关于 XML 的更多内容。
结束语
从本系列上一篇文章开篇起,我几乎一直在谈论 XML,但对于 XML 在 Ajax 应用模式中的贡献而言,我触及的依然仅仅是表面。在下一期文章中,您将更详细地了解那些您将希望 发送 XML 的特殊场景(还会看到那些需要接收 XML 的场景)。具体来说,您会在 Ajax 交互的角度上观察 Web 服务 —— 包括专有 Web 服务和 Google 那样的 API。
简而言之,最重要的任务就是思考对于您的应用程序,XML 在什么时候才是有意义的。在很多情况下,如果您的应用程序工作良好,XML 只不过是又一个让您头疼的技术时髦词汇,您应该克制住仅仅为了宣称应用程序中有 XML 而尝试它的冲动。
如果您处于这样一个环境中:服务器向您发送的数据非常有限,或者采用的是奇怪的逗号分隔、竖线分隔的格式,那么 XML 可能会给您带来真正的收益。考虑处理或更改您的服务器端组件,以使它们用更为标准化的方式 —— 使用 XML —— 来返回响应,而不是使用那些健壮性比 XML 差的专用格式。
最重要的是,要认识到,您对 Ajax 相关技术了解的越多,就必须越谨慎地制定决策。编写那些 Web 2.0 应用程序确实很有趣(在后续文章中,您将重返用户界面,看看可以在这里做些什么很酷的东西),但要注意,确保您不是为了向朋友炫耀而在一个可以正常工作的 Web 页面上滥用这些技术。我确信,您能编写出优秀的应用程序,那么就动手去做吧。完成后,再回来阅读下一期文章,学习关于 XML 的更多知识。