审视 Ajax，第 2 部分: 使用 mashup 改变您的生活

要避开的陷阱，未来的巨大机遇

文档选项

将此页作为电子邮件发送

最新推荐

Java 应用开发源动力 － 下载免费软件，快速启动开发

级别: 初级

Chris Laffra ([e-mail]), 性能工程团队主管, IBM

2006 年 9 月 11 日

Chris Laffra 的这篇文章继续讨论 Ajax 开发人员在开发应用程序时需要记住什么。除了具体的建议和忠告外，还展望了 Ajax 的未来，它推动了个人网页上内容的用户导向型混合。

本系列的第一期文章中，我讨论了目前环绕着 Ajax 的不实之词。您还了解到，可靠的框架仍然未完成，应该考虑导航历史、书签功能、反馈、持久性、并发安全问题。

接下来的这篇文章中，主题是文档重绘、测试、发布和订阅问题、性能、可访问性、对老版本浏览器的支持以及宣称自己的目标。我还将提到 Ajax 带来的一种有趣的可能性：在网站中开发网站。

迷路了

移动鼠标光标对应用程序而不是用户来说是一个糟糕的主意。这是一条众所周知的用户界面（UI）设计法则，无论代价多大都应避免这种移动。Ajax 应用程序也有类似的规则：不要替我滚动窗口。如果异步的 Ajax 响应从服务器上返回，文本被粘贴到当前文档视图上方的 DOM 元素中，浏览器就会向下滚动内容。结果是让人摸不着东西南北。

Ajax 的问题是把文档看成它并不是的东西。Google Maps 没有这个问题 —— 基本上不需要滚动条。这是因为它实际上就象一个应用程序。但是，如果很长的 GMail 贴子，迷路的危险就很现实，因为有滚动条，点击任何一栏都会重新排列窗口的内容及其滚动条。

如果最终结果在当前视点之前，将文档看作应用程序的 Ajax 应用程序应该避免更新文档。视点管理和有条件的 DOM 操作不是可有可无的，因此 Ajax 应用程序本身应该准备好忽略 返回时间太长的响应。为了保持连贯性，最好增加重试或刷新按钮。

建议：明确避免移动滚动条这类智能化操作。

回页首

测试

“不停地测试，产品就会不断地改进。”—— David Ogilvy

Ajax 开发是一种多平台的开发，需要进行多平台测试。细微的差别、不兼容的事件模型、难以协调的 DOM 不兼容性等等迫使 Ajax 开发人员编写防卫代码来处理种种差别。

大多数自动化的屏幕测试工具都明确宣称不支持 DHTML。由于动态 HTML 移动页面对象和动态改变 DOM 结构，自动测试工具无法知道 UI 到底是什么样子，更重要的是，不知道如何驱动它。想想 Start.com 的网站，怎么来测试它。我想不出您有什么办法，除非低价雇佣大批志愿测试者。

虽然 JavaScript 使得自动化测试更加困难，但 Ajax 有一个优点：服务器上服务的组件化（原子化）允许对业务逻辑进行更小粒度的测试。从而能够进行高覆盖和可变性的函数测试。

回页首

推在哪儿？

图 1 显示了过去的一个神话：基于 PointCast 的推技术。

图 1. 推技术的应用

PointCast 大约在 1996 年引起了一个神话般的风潮，它提供了一个免费阅读器可以在网络上推免费的内容（和广告）。PointCast 2.6 需要一台 486/33 处理器、8 MB 内存、10 MB 磁盘空间的 PC 机，照今天的标准来看简直太低了。

如果比较 PointCast UI 和 Start.com 就会发现惊人的相似。当然人们要问 Ajax 比 PointCast 强在哪儿。除了高分辨率图像、阴影和平滑拖动所体现的高保真性以外，基本上 Ajax 对用户关注什么仍然只能提供有限的信息。

Ajax 缺少对发布-订阅体系结构的支持，因为除了 HTTP 流之外，没有打开到 IP 地址的稳定套接字连接的标准方式。比方说，通过 Flash 的 XMLSocket 对象和 Flash/JavaScript Integration Kit，Ajax 应用程序可以打开到 MQSeries 服务器的稳定的全双工 TCP/IP 套接字流。但是，这种应用程序需要在客户机浏览器上安装 Flash 播放器。目前，Ajax 应用程序只能轮询加载它们的服务器，本质上是把服务器作为到数据服务器的代理/网关使用。这可能会给网络增加额外的负担，服务器也不大可能经受住数千甚至几百万（成功的代价）用户不断地轮询。需要一种新的体系结构。

回页首

CPU 和泄漏

现代桌面计算机变得越来越快，但是把代码从服务器环境转移到桌面上意味着把要求放在不那么容易升级的环境中。内存越来越便宜，512 MB 只要 25 美元，但是考虑到要安装的基数，成本也是惊人的。慢的机器将来不及处理那些 DHTML 动画和 DOM 操作生成的命令。在 HTML 内容以外发送的代码越多，网站加载的速度越慢。

大多数人不知道，JavaScript 就有泄漏的倾向。如果不小心，浏览器的内存需求将在整个浏览会话周期中不断增加。过去 CPU 的效率限制了 JavaScript 的采用。随着浏览器变得越来越快，部分原因要归功于激烈的竞争，记住，很多用户的桌面机并没有一般开发人员机器装备的那么好。

回页首

可访问性

残疾人士的可访问性很少受到一般开发人员的关注。但即便没有法律上的要求，开发人员还面临着道德问题，必须考虑让残疾人士能够访问网站的技术准备。由于声明性特性，HTML 利用本身非常简单解决了这个问题：比方说，屏幕阅读器可以处理它，视觉偏弱的用户可使用大字体。

动态 HTML 给网站带来的是不断改变其结构。盲文计算机、屏幕阅读器和基于语音指令的导航工具很难应付这种不断的变化。

回页首

JavaScript：还没有普及

thecounter.com 2005 年 10 月对浏览器的统计结果表明，全部 Web 浏览器中有 10% 关闭了 JavaScript 或者不支持。这要好于 2001 年的 16%，但是网站还是要面对那些不想运行 JavaScript 的用户。

不支持 JavaScript 的最知名的一类浏览器是搜索机器人。依赖于 Ajax 技术的网站必须特别注意保证自己仍然出现在搜索查询中。meta 中的关键字可以帮助定向搜索引擎。另一方面，对于向包打听似的搜索机器人隐藏 某些内容 Ajax 可能很有用。

回页首

目的

传统上，Web 上的链接把您带到另一个地方，所有用户都知道并期望这一点。此外，底层的 GET 请求被认为是无状态的。虽然据我所知还没有标准，但是浏览器和搜索引擎都认为 GET 请求服务的链接是无状态的。如果 Ajax 应用程序使用链接来改变状态，那么相关各方就会被搞糊涂的，包括可怜的用户。

不要期望用户非常灵活，知道如何通过在屏幕上拖拉来个性化自己的体验。他们可能根本不想这么做。此外，还需要用清楚、明确的话告诉用户要做什么，这可能是美国有这么多路标中包含文字的原因吧。一个领域的比喻，比方说 Linux/PHP 脚本黑客，不一定适用于其他领域，比如 50 岁的保险推销员。有些直观的比喻可能在一种文化中很酷，而在其他文化中可能是无礼的行为。

简言之，您需要明确说明自己的目的，尽可能减少交互的次数，并假设您的用户中有新手和没有经验的用户。个性化很重要，但是不要将其添加到应用程序中而损失可用性，也不要让它妨碍国际化支持之类的实现。

回页首

混合

“现在，很多软件存在不是为了解决问题而是为了和其他软件交互。”—— I.O. Angell

多数 Ajax 应用程序发出的信息是促进聚合。Ajax 的优点经常被描述为减少了与服务器之间往复的成本。但是，如果 Ajax 应用程序跨过简单的门户阶段而执行真正透明的客户端混合（mashup），其优点才会显现出来，如 图 2 所示。

图 2. Ajax 的真正潜力？

比方说，个性化的 Google 和 Start.com 都执行 Web 搜索然后把结果保存到当前页面中。Cookie 和服务器端存储或 Flash 对象可以持久当前页面布局，因此下一次访问该页面时，原来选择的混合仍然保留着。Google 和 Start.com 都提供了用户定义构件允许开发人员定义自己的 portlet。但仍然没有超越门户的阶段。

Ajax 要想真正成功，它必须消失。这需要 Greasemonkey（请参阅 参考资料）客户端的、用户可编程的版本，允许设计人员和高级用户聚合自己的信息源和定义自己的表示。这些功能变得越来越近，但是需要更简化的编程模型，否则只有 Google 或 Microsoft 的那些大师才能开发这类应用程序。

作为一个具体的例子，我建立了一个 客户驱动的混合演示。没有依靠服务器创建自定义的网页，页面全部是由 JavaScript 完成的。这个例子说明了如何从 (a) HTML 收集信息，使用 weather.com 获得本地气温；(b) 运行在远程服务器上的 SQL 数据库；和 (c) RSS 提要 —— 这里使用这些提要来聚合新闻。我要做的就是统一信息采集、转换和混合成统一的风格。演示页面上提供了源代码，看看声明性的模板如何进行 HTML 转换和完成一些简单的业务逻辑（单击演示页面上的 src 链接）。

回页首

现场编辑

很多 wiki 允许用户在丰富文本编辑器中编辑页面片段的内容然后发布到服务器上，整个过程不用离开浏览器。类似地，也可以不用安装开发环境而组合应用程序（如果愿意这么说的话）。Ajax 技术允许越来越多的网站设计工作在显示它们的同一个环境中完成。我称之为现场编辑。有人称这种现象为现场编程。我提供的演示可以编辑 DOM 片段，您可以看看它是如何工作的。

回页首

持久

HTML文档如何修改自身然后持久到文件系统的一个例子是 TiddlyWiki（请参阅 参考资料）。如果查看 TiddlyWiki，就下载了整个应用程序，因为它完全是作为网页中的 JavaScript 应用程序工作的。HTML 在现场编辑（即几秒钟之前查看了它的同一个浏览器窗口），保存到本地文件系统中。

如果不愿意在本地硬盘上保存，可使用 WebDAV 之类的技术在 Web 上共享和版本化资源。使用 WebDAV 并不是能够上传通过现场编辑会话更新网页的惟一技术。另一种办法是使用 XmlHTTPRequest 并连接到 REST 服务而自己上传网页。后一种技术要求专门的服务来接收 XML 请求和维护页面的不同版本，虽然用几行 PHP 代码就能编写这样的服务器扩展。

我提供了 一个例子 说明如何从当前页面中提取文档 DOM、传递到服务器、然后重新加载到浏览器（甚至可以是其他浏览器）。请参阅示例页面中的源代码，很容易自己实现。

回页首

结束语

现在，您已经了解了在网站项目中应用 Ajax 技术应该考虑的潜在问题。不要太灰心；Ajax 包含一些很好的技术，改善了网站的响应性，扩展了应用，并且可以在浏览器中进行丰富客户机应用程序开发。学习那些成功的 Ajax 应用程序，采纳有效的部分，不要重复别人的错误。如果您能做到这些，您就能创建一个您奶奶见过的最棒的网站！

回页首

参考资料

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
  
  
• developerWorks 中国网站 Ajax 技术资源中心：在这里您可以找到更多关于 Ajax 的知识，包括 Ajax 基础入门、使用 Java, PHP 等语言开发 Ajax 应用的各种技巧和多种 Ajax 框架的技术信息。
  
  
• 作者编写了三个 Ajax 示例应用程序帮助您理解本文中的概念和了解 Ajax 的潜力：
  • 客户机驱动的混合
  • 可编辑 DOM 片段的演示
  • 说明如何从当前页面提取文档 DOM、传送到服务器然后重新加载的例子
  
  
• “审视 Ajax，第 1 部分：透过华而不实的广告看本质”（Chris Laffra，developerWorks，2006 年 5 月）：阅读本系列的第一篇文章，了解何时以及如何实现这种新技术。
  
  
• Alex Bosworth 的 Ajax 错误列表：看看促使作者撰写本系列文章的灵感来源。
  
  
• Web Accessibility Initiative：如何使网站能够被残疾人访问。
  
  
• mashup：Wikipedia 很好地解释了这个词在 Web 应用程序环境中的含义。
  
  
• thecounter.com：看看浏览器的现状。
  
  
• developerWorks Web 架构专区：关于 Web 技术的文章和教程可以提升您的网站开发技能。
  
  
• developerWorks 技术事件和网络广播：关注拥挤不堪的技术会议，可以缩短您的学习曲线，改进最困难的软件项目的质量和结果。
  
  

获得产品和技术

• Google Maps：一个成功的、有影响的 Ajax 应用程序。
  
  
• Greasemonkey：用这个工具分析在线运行的 Ajax 应用程序。
  
  
• TiddlyWiki：创建个人的自含的超文本文档。
  
  

讨论

• 参与论坛讨论。
  
  
• developerWorks blogs：加入 developerWorks 社区。
  
  
• developerWorks 讨论论坛：参加您感兴趣的讨论。

回页首

关于作者

Chris Laffra 出生于荷兰，1988 年从阿姆斯特丹 Vrije 大学获得理学硕士学位，1992 年从鹿特丹的 Erasmus 获得博士学位。Chris 为 IBM T.J. Watson Research Center 和 Morgan Stanley 工作，从事用户界面、部件基础设施、程序分析、调试、可视化、压缩和优化方面的研究。他曾经领导 OTI 阿姆斯特丹实验室三年半，开发 WebSphere Studio Device Developer。在渥太华的 IBM 加拿大试验室，他研究 Java 运行时环境和 Eclipse 之间的分界（并与人合作撰写了 Official Eclipse 3.0 FAQs）。目前，Chris 作为 IBM Rational Performance Engineering 团队的主管，负责研究改进 RAD/RSA 的性能。他使用 Ajax 很长时间了，包括改进 Google Maps 以便在 Raleigh 找到附近有一所好学校的新房子，生成 Eclipse FAQs 的在线版本。