率地讲，Ajax并不是什么新鲜玩艺。实际上，与这个词相关的“最新”术语就是XMLHttpRequest对象（XHR），它早在IE 5（于1999年春天发布）中就已经出现了，是作为 Active X控件露面的。不过，最近出现的新现象是浏览器的支持。原先，XHR对象只在IE中得到支持（因此限制了它的使用），但是从Mozilla 1.0和Safari 1.2开始，对XHR对象的支持开始普及。这个很少使用的对象和相关的基本概念甚至已经出现在W3C标准中：DOM Level 3 加载和保存规约（DOM Level 3 Load and Save Specification）。现在，特别是随着Google Maps、Google Suggest、Gmail、Flickr、Netflix和A9等应用变得越来越炙手可热，XHR也已经成为事实上的标准。
与前面几页提到的方法不同，Ajax在大多数现代浏览器中都能使用，而且不需要任何专门的软件或硬件。实际上，这种方法的一大优势就是开发人员不需要学习一种新的语言，也不必完全丢掉他们原先掌握的服务器端技术。Ajax是一种客户端方法，可以与J2EE、.NET、PHP、Ruby和CGI脚本交互，它并不关心服务器是什么。尽管存在一些很小的安全限制，你还是可以现在就开始使用Ajax，而且能充分利用你原有的知识。
你可能会问：“谁在使用Ajax？”前面已经提到，Google显然是最早采用Ajax的公司之一，而且已经用在很多技术上，随便说几个应用，如Google Maps、Google Suggest和Gmail。Yahoo!也开始引入Ajax控件，另外Amazon提供了一个简洁的搜索工具，其中大量使用了这个技术，例如，在钻石的某一方面上移动滑块，这会带来动态更新的结果（见图1-5）。并不是每次改变你的查询标准时都会更新页面，而是在移动滑块时就会查询服务器，从而更快、更容易地缩小你的选择范围。
图1-5 Amazon的钻石搜索页面
Netflix是一家很有名的DVD租借公司，它也使用了Ajax。当用户浏览影片时，可以得到更详细的信息。当顾客把鼠标放在一个影片的图片上时，这个影片的ID就会发送到中心服务器，然后会出现一个“气泡”，提供这个影片的更多细节（见图1-6）。同样，页面并不会刷新，每个影片的详细信息并不是放在隐藏的表单域中。利用这种方法，Netflix可以提供影片的更多信息，而不会把页面弄乱。顾客浏览起来也更容易，他们不必点击影片，看完影片详细信息后再点击回到影片列表页面；他们只需把鼠标停在影片上，就这么简单！我们想要强调的是，Ajax并不限于.com之类的网站使用，普通公司的开发人员也开始涉足这个技术，有些人已经在使用Ajax来改善原来很丑陋的验证方案，或者用于动态地获取数据了。
图1-6 Netflix的浏览页面特性
关键在于，因特网默认的请求/响应模式有了重大转变，这正是Ajax的核心所在，尽管这并非全新的内容。Web应用开发人员现在可以自由地与服务器异步交互，这说明他们可以完成许多原本只能在胖客户上完成的任务。例如，当用户输入邮政编码时，可以验证它是否正确，然后自动用相应的城市名和州名填充到表单中的其他部分；或者，当用户选择美国时，可以引入美国各个州的一个下拉列表。以前也可以用其他方式模拟这些工作，但是使用Ajax的话，这些工作会更加简单。
那么，是谁发明了Ajax？要找出真正的源头，总免不了一场争论。不过有一点是确定的，2005年2月，Adaptive Path的Jesse James Garrett最早创造了这个词。在他的文章Ajax: A New Approach to Web Applications（Ajax：Web应用的一种新方法）中，Garrett讨论了如何消除胖客户（或桌面）应用与瘦客户（或Web）应用之间的界限。当然，当Google在Google Labs发布Google Maps和Google Suggest时，这个技术才真正为人所认识，而且此前已经有许多这方面的文章了。但确实是Garrett最早提出了这个好名字，否则我们就得啰啰嗦嗦地说上一大堆：异步（Asynchronous）、XMLHttpRequest、JavaScript、CSS、DOM等等。尽管原来把Ajax认为是Asynchronous JavaScript + XML（异步JavaScript + XML）的缩写，但如今，这个词的覆盖面有所扩展，把允许浏览器与服务器通信而无需刷新当前页面的技术都涵盖在内。
你可能会说：“哦，那有什么大不了的？”这么说吧，使用XHR而且与服务器异步通信，就能创建更加动态的Web应用。例如，假设你有一个下拉列表，它是根据另外一个域或下拉列表的输入来填写的。在正常情况下，必须在加载第一个页面时把所有数据都发送给客户端，然后使用JavaScript根据输入来填写下拉列表。这么做并不困难，但是会让页面变得很臃肿，取决于这个下拉列表到底有多“动态”，页面有可能膨胀得过大，从而出现问题。利用Ajax，当作为触发源的域有变化，或者失去了输入焦点，就可以向服务器发一个简单的请求，只要求得到更新下拉列表所需的部分信息即可。
来单独考虑一下验证。你写过多少次JavaScript验证逻辑？用Java或C#编写验证逻辑可能很简单，但是由于JavaScript缺乏很好的调试工具，再加上它是一种弱类型语言，所以用JavaScript编写验证逻辑实在是一件让人头疼的事情，而且很容易出错。服务器上还很有可能重复这些客户端验证规则。使用XHR，可以对服务器做一个调用，触发某一组验证规则。这些规则可能比你用JavaScript编写的任何规则都更丰富、更复杂，而且你还能得到功能强大的调试工具和集成开发环境（IDE）。
你现在可能又会说：“这些事情我早已经用IFRAME或隐藏框架做到了。”我们甚至还使用这种技术来提交或刷新过页面的一部分，而不是整个浏览器（页面）。不能不承认，这确实可行。不过，许多人认为这种方法只是一种修补手段，以弥补XHR原来缺乏对跨浏览器的支持。作为Ajax的核心，XHR对象设计为允许从服务器异步地获取任意的数据。
我们讨论过，传统的Web应用遵循一种请求/响应模式。如果没有Ajax，对于每个请求都会重新加载整个页面（或者利用IFRAME，则是部分页面）。原来查看的页面会放到浏览器的历史栈中（不过，如果使用了IFRAME，点击“后退”按钮不一定能得到用户期望的历史页面）。与此不同，用XHR做出的请求不会记录在浏览器的历史中。如果你的用户习惯于使用“后退”按钮在Web应用中进行导航，就可能会产生问题。
前面谈到的都是用户的期望，除此以外，可用性也不能不提。Ajax方法相当新，还没有多少成熟的最佳实践。不过，标准Web设计原则还是适用的。随着时间推移，当越来越多的人开始尝试这种方法时，就会发现可能存在哪些限制，并建立适当的指导原则。也就是说，你应该让用户来指导你。根据在应用中使用Ajax的方式，你可能会动态地改变页面中的某些部分，习惯于整个浏览器刷新的用户可能不会注意到与以前相比有什么变化。这个问题引出了一些新的特性，如37signals所普及的黄褪技术（Yellow Fade Technique，YFT），这个特性已经用在Ajax的招牌应用Basecamp中了。
基本说来，YFT是指“取页面中有变化的部分，并置为黄色”。假设你的应用原本没有大量使用黄色，用户就很可能会注意到这种改变。过一段时间后，再让黄色逐渐褪色，直到恢复为原来的背景色。当然，你也可以选用你喜欢的其他颜色，只要能把用户的注意力吸引到有变化的部分。
可能YTF并不适用于你的应用，你也可以选择用一种不那么张扬但仍很有用的方式来提醒用户。Gmail在右上角显示了一个闪动的红色“Loading”加载记号，提醒用户正在获取数据（见图1-7）。
图1-7 Gmail的“Loading”记号
究竟要使用YFT还是其他类似的技术，实际上取决于你的用户。最简单的方法是让一组用户代表来进行测试。可以通过文字问卷，也可以使用基于Web的原型应用，这要看你处在设计过程的哪个阶段。但是不论如何测试，在真正采用Ajax完成复杂设计之前都应该取得一些用户反馈。
而且要从小处做起。在刚开始使用Ajax时，不应该马上就创建一个可调整列的动态门户网站，而是应该先试着处理客户端验证，逐步转向服务器端。待有所了解后，可以再尝试更动态的使用，如填写一个下拉列表，或者设置某些默认文本。
不管你要如何应用Ajax，记住别做稀奇古怪的事情。我们知道，这不算是一个学术性的建议。不过，目前这方面还没有严格的规则。先听听用户怎么说，部署之前一定要先做测试，而且要记住，如果太过古怪，用户很快就会点击“跳过本页”链接跳过你精心设计的这些部分。
要知道使用Ajax 时有几个常犯的错误。我们已经讨论过，有变化时如何向用户提供可视化的提示，不仅如此，Ajax还会以其他方式改变标准的Web方法。首先，不同于IFRAME和隐藏框架，通过XHR做出请求不会修改浏览器的历史栈。在许多情况下这没有什么问题（你可能会点击后退箭头，只是要看看是不是什么都没有改变，但这么做能有几次呢？），不过，如果你的用户确实想用后退按钮，就有问题了。
其次，与其他基于浏览器的方法不同，Ajax不会修改地址栏中显示的链接，这表明你不能轻松地为一个页面建立书签，或者向朋友发送一个链接。对于许多应用来说，可能没有这个要求，但是如果你的网站专门为人提供行车路线之类的东西，就要针对这个问题提供一个解决方案。
有一点很重要，使用Ajax不要过度。记住，JavaScript会在客户端的浏览器上运行，如果有数千行JavaScript代码，可能会让用户感觉速度太慢。如果脚本编写不当，就会很快失去控制，特别是当通信量增加时。
Ajax允许你异步地完成操作，这个最大的优点同时也是它最突出的缺点。我们以前总是告诉用户，Web应用是以一种请求/响应模式完成操作的，用户也已经接受了这种思想。但是用了Ajax，就不再有这个限制。我们可以只修改页面的一部分，如果用户没想到这一点，他们很可能会被搞糊涂。所以，你要注意一定要让用户明白这一点，不要想当然地以为他们知道。记住，只要有疑问，就要请用户代表进行测试！
当你看到本书时，可能已经了解了在应用中实现Ajax所需的大多数技术。重申一句，我们想强调的是，Ajax是一个客户端技术，不论你现在使用何种服务器端技术，都能使用Ajax，而不管使用的是Java、.NET、Ruby、PHP还是CGI。实际上，在这本书中我们并不考虑服务器端，而且假设你已经很清楚如何结合日常工作中使用的服务器端技术。在后面的几百页中，我们强调的重点是客户端技术和方法，创建丰富的基于浏览器的应用时需要用到这些技术。
尽管可以使用你喜欢的任何服务器端技术，但当使用Ajax时还是需要转变一下思想。在一般的Web应用中，服务器端代码会呈现一个完整的页面，并涉及一个完整的工作单元。利用Ajax，可能只返回一点点文本，而且只涉及一个业务应用的很小子集。对于大多数有经验的Web开发人员来说，理解起来没有什么问题，但是一定要记住这一点。
一些新兴的框架有助于开发人员跳出Ajax的一些细节。不过，你还是要对JavaScript有所了解。我们知道
上一页 [1] [2] [3] [4] [5] 下一页
