Chris Laffra 的这篇文章继续讨论 Ajax 开发人员在开发应用程序时需要记住什么。除了具体的建议和忠告外，还展望了 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 机，照今天的标准来看简直太低了。