Web应用的发展历程

8、 基本问题

有了以上了解，你怎么想？即使是要求最苛刻的客户应用，也已经把Web作为首选平台。很显然，基于Web的应用很容易部署，这种低门槛正是Web应用最耀眼的地方。由于浏览器无处不在，而且无需下载和安装新的软件，用户利用基于浏览器的客户端就能很轻松地尝试新的应用。用户只需点击一个链接就能运行你的应用程序，而不用先下载几兆比特的安装程序才行。基于浏览器的应用也不考虑操作系统是什么，也就是说，不仅使用不同操作系统（如Linux和Mac OS X）的人能运行你的应用程序，而且你也不必考虑针对不同的操作系统开发和维护多个安装包。

 既然基于Web的应用是前所未有的好东西，那我们为什么还要写这本书？如果回头看看因特网的起源就可以知道，最初因特网实际上就是为了科学家们和学术机构间交换文章和研究成果，这是一种简单的请求/响应模式。那时不需要会话状态，也不需要购物车，人们只是在交换文档。但现在你有很多办法来创建动态的Web应用，如果想让应用真正深入人心，赢得大量的用户，就必须在浏览器上大做文章，这说明，因特网以请求/响应模式作为基础，由此带来的同步性对你造成了妨碍。

与Microsoft Word或Intuit Quicken之类的胖客户应用相比，Web模型当然只能根据一般用户需要做折中考虑。不过，由于Web应用很容易部署，而且浏览器的发展相当迅速，这意味着大多数用户都已经学会了适应。但是，还是有许多人认为Web应用只能算“二等公民”，给人的用户体验不是太好。因为因特网是一个同步的请求/响应系统，所以浏览器中的整个页面会进行刷新。最初，这种简单的请求并没有什么问题。如果用户做了一两处修改，就必须向服务器发回整个文档，而且要重新绘制整个页面。尽管这样是可行的，但是这种完全刷新的局限，意味着应用确实还很粗糙。

这并不是说开发人员只是袖手旁观，全然接受这种状况。Microsoft对于交互式应用有一定了解，而且对于这种标准请求/响应模式的限制一直都不满意，因此提出了远程脚本（remote scripting）的概念。远程脚本看似神奇，其实很简单：它允许开发人员创建以异步方式与服务器交互的页面。例如，顾客可以从下拉列表中选择状态，这样就会在服务器上运行一个脚本，计算顾客的运费。更重要的是，显示这些运费时无需刷新整个页面！当然，Microsoft的方案只适用于它自己的技术，而且需要Java，但有了这个进步，说明更丰富的浏览器应用并不是海市蜃楼。

对于同步页面刷新问题还有其他一些解决方案。针对Microsoft的远程脚本，Brent Ashley在创建JavaScript远程脚本（JavaScript Remote Scripting，JSRS）时开发了一个平台中立（独立于平台）的方案。JSRS依赖于一个客户端JavaScript库和DHTML，可以向服务器做异步的调用。与此同时，许多人利用了IFRAME标记，可以只加载页面中的某些部分，或者向服务器做“隐藏”的调用。尽管这是一个可行的方法，而且也为很多人所用，但它肯定不是最理想的，还有待改善。

9、 Ajax

终于谈到这里了：客户希望得到一个功能更完备的应用，而开发人员想避开繁琐的部署工作，不想把可执行文件逐个地部署到数以千计的工作站上。我们已经做过很多尝试，但是任何方法都不像它原来标榜的那么完美。不过，最近一个极其强大的工具横空出世了。

是的，我们又有了一个新的选择，新的工具，可以创建的确丰富的基于浏览器的应用。这就是Ajax。Ajax不只是一个特定的技术，更应算是一种技巧，不过前面提到的JavaScript是其主要组件。我们知道，你可能会说“JavaScript根本不值一提”，但是由于Ajax的出现，人们对这种语言又有了新的兴趣，应用和测试框架再加上更优秀的工具支持，减轻了开发人员肩头的重担。随着Atlas的引入，Microsoft对Ajax投入了大力支持，而名声不太好的Rails Web框架也预置了充分的Ajax支持。在Java世界中，Sun已经在其BluePrints Solutions Catalog中增加了许多Ajax组件。

坦率地讲，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）。并不是每次改变你的查询标准时都会更新页面，而是在移动滑块时就会查询服务器，从而更快、更容易地缩小你的选择范围。

Netflix是一家很有名的DVD租借公司，它也使用了Ajax。当用户浏览影片时，可以得到更详细的信息。当顾客把鼠标放在一个影片的图片上时，这个影片的ID就会发送到中心服务器，然后会出现一个“气泡”，提供这个影片的更多细节（见图1-6）。同样，页面并不会刷新，每个影片的详细信息并不是放在隐藏的表单域中。利用这种方法，Netflix可以提供影片的更多信息，而不会把页面弄乱。顾客浏览起来也更容易，他们不必点击影片，看完影片详细信息后再点击回到影片列表页面；他们只需把鼠标停在影片上，就这么简单！我们想要强调的是，Ajax并不限于.com之类的网站使用，普通公司的开发人员也开始涉足这个技术，有些人已经在使用Ajax来改善原来很丑陋的验证方案，或者用于动态地获取数据了。

关键在于，因特网默认的请求/响应模式有了重大转变，这正是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应用中进行导航，就可能会产生问题。