当前位置:   article > 正文

ajax学习笔记

ajax最早是由adaptive path 公司的jesse james garrett于1995年2月在文章《ajax:a

本文引用了《Ajax高级程序设计》与《Ajax in action》的部分内容

什么是ajax

2005 年2月,Adaptive Path公司的Jesse James Garrett在网上发表了一篇名为《Ajax:一种Web应用程序开发的新方法》的文章。在这篇文章中,Garrett阐述了他为什么认为Web应用程序正在填平与传统桌面应用程序之间的鸿沟。他引用了一些新的技术,并以几个Google的项目作为例子,说明了如何将传统的、基于桌面应用程序的用户交互模型应用到Web上。然后他说出了两句引起人们大量兴趣、兴奋和争论的话:

Google Suggest和Google Maps就是这种新型Web应用程序的两个例子,在Adaptive Path公司里,我们将这种理念称为 Ajax。这是Asynchronous(异步)JavaScript + XML的简写,它预示着Web可能将发生一次根本性的变革。

从此之后,关于Ajax的文章、示例代码以及争议有如潮水一般充斥于整个因特网上。开发人员在Blog上谈到它,技术杂志关注它,而许多公司则在产品中应用它。但要理解到底什么是Ajax,还必须先了解促使其产生的一些Web技术的演化过程。

Web的演化过程

当Tim Berners-Lee在1990年首次提出World Wide Web(万维网)时,其概念是相当简单的:使用超文本和URI(统一资源标识符)来创建一个关联信息的网,它能够链接来自世界各个地方的各种学术文献,使人们可以立即访问所引用的素材。的确,第一版本的HTML(超文本标记语言)对于格式化和链接之外的事情关注得很少,它并不适用于构建交互性强的软件,只是一个用来共享最新的各种文字和图表信息的平台。Web就是从这样的静态页面开始发展的。

随着Web的发展,商业界很快就发现了它在向大众发布产品及服务信息等应用上所具有的优势。紧接下来的新一代Web 则着眼于提高信息的格式化和显示能力,而HTML也随之发展,以满足这些需求和这些新的媒体意识强烈的用户期望。很快,一家名为Netscape的小公司将推动Web的发展进程迈出更迅速的一步。

JavaScript


Netscape Navigator是第一个成功的主流Web浏览器,同样也使Web技术得以快速发展。但是,Netscape在标准出台之前(就像现在微软在IE的开发中忽视现有标准而遭到批评一样)就开发新技术或对原有技术进行扩展的做法,却经常遭到标准化组织的批评。JavaScript就是这种技术中的一个。

JavaScript原名为LiveScript,是Netscape公司的Brendan Eich开发的,包含于Navigator浏览器2.0版本(发布于1995年)之中。开发人员第一次能够控制页面与用户之间的交互。对于诸如数据验证这样的简单任务,不再需要持续地在服务器和客户端之间往返,只需在浏览器中就可以实现。对于大部分因特网用户都还是通过28.8Kbit/s的调制解调器实现连接的时代而言,这一能力是十分重要的,因为那时向服务器发送每个请求就像是一个等候游戏。使用户等候响应的次数尽可能地小,这是朝着Ajax方法发展的第一个重要步骤。


HTML的最初版本将每个文档都看作是独立的,直到HTML 4.0版,帧(frame)还没有正式引入。帧的理念是使一个网页能够分成几个独立的文档,由于Netscape在HTML 4.0还没有完成时就实现了该功能,因而引发了争议。Netscape Navigator 2.0是第一个同时支持帧和JavaScript的浏览器。这是Ajax演化进程中的一个重要步骤。

20世纪90年代末,当微软和Netscape之间的浏览器之战爆发之后,JavaScript和帧都被纳入了正式的标准之中。随着它们功能的不断增加,富于创新的开发人员开始尝试将它们集成在一起使用。由于帧表示的是一个完全独立的对服务器的请求, JavaScript能够控制帧及其内容的能力,使实现某些令人兴奋的效果成为了可能。

隐藏帧技术


当开发人员掌握操作帧的方法之后,也就为客户端—服务器通信引入了一种有效的工具。隐藏帧技术是指配置一个帧集(frameset),使其中一个帧的宽度或高度为0像素,其唯一的功能就是用来初始化与服务器的通信。隐藏帧可以包含一个HTML表单,表单中包含一些特定的字段,这些字段能够通过JavaScript实现动态填充,并将其发回到服务器端。当返回该帧时,将会调用另一个JavaScript函数,以提示数据已经返回了。隐藏帧技术是Web应用系统中第一个异步请求/响应模型。

然而这只是第一个Ajax通信模型,另一个技术进展已经不远了。

动态HTML和DOM


直到1996年左右,Web的主流还是静态页面。尽管JavaScript和隐藏帧技术能使用户交互更具活力,但除了重载页面之外仍然没有改变页面内容显示的方法。紧接着,IE 4.0发布了。

在此时,IE引入了动态HTML(DHTML)技术,凭借该技术IE成功地赶上了市场的领导者Netscape Navigator,甚至还占了上风。尽管还在开发阶段,但DHTML还是代表了从静态网页向前迈出的重要一步,它使得开发人员能够通过 JavaScript来修改已载入页面的任何部分。随着CSS(层叠样式表)的出现,DHTML使Web开发重现活力,尽管早期微软和Netscape所遵循的路线有很大的不同。开发社区感到振奋是可以理解的,因为将DHTML和隐藏帧技术组合在一起,就意味着可以随时根据服务器的信息来更新页面的任何部分,这才是Web开发的一次真正的范型转变(paradigm shift)。

但DHTML却从来没有被纳入标准,尽管微软的影响随着DOM(文档对象模型)成为标准工作的中心变得更加强大。与 DHTML只追求修改网页的某个片段不同,DOM有一个更雄心勃勃的目标:为整个网页提供一个标准结构,对该结构的操作将使修改DHTML风格的页面成为可能。这是向Ajax方法发展的下一个重要步骤。

iframe


尽管隐藏帧技术流行得令人难以置信,但它仍然存在一个不足:必须提前计划,为可预见的隐藏帧设置帧集。在1997年,<iframe/>元素作为HTML 4.0官方标准的一部分引入,这是Web进化过程中另一个重要步骤。

开发人员可以在页面的任何地方放置iframe,而不必定义帧集。它可以使开发人员把前面提到的帧集完全抛之脑后,只需简单地在页面中放置隐形的iframe(通过使用CSS),以完成客户端到服务器的通信。当DOM最后在IE 5.0和Netscape 6.0中实现时,还能够动态地在运行时创建iframe,也就是意味着JavaScript函数能够创建iframe,发出请求,获取响应,并且在页面中不需任何额外的HTML元素。这就是新一代的隐藏帧技术:隐藏iframe技术。

XMLHttp


微软的浏览器开发人员肯定了解到隐藏帧技术和新的隐藏iframe技术的广为流行,因为他们决定向开发人员提供一个实现客户端—服务器交互的更好的工具。这个名为XMLHttp的工具是在2001年以ActiveX对象的形式引入的。

微软的JavaScript扩展可以用来创建ActiveX控件这种微软专有的程序对象。当微软通过一个名为 MSXML的库来提供XML支持时,就引入了XMLHttp对象。虽然名字中有XML,但是这个对象更像是操作XML数据的另一种方法。实际上,它更像是一个能够在JavaScript中进行控制的特定HTTP请求。开发人员可以像处理其他从服务器端返回的数据一样,访问其HTTP状态代码和首部信息。这些数据可能以XML格式组织,也可能预格式化为HTML、序列化为JavaScript对象或者采用开发人员预想的其他格式。现在可以独立于页面的载入/ 重载周期,使用纯JavaScript通过程序访问服务器,而不再需要使用隐藏帧或隐藏iframe技术。XMLHttp对象对IE开发人员而言有着巨大的影响。

随着使用者不断增加,开源项目Mozilla的开发人员也开始移植XMLHttp。为了避免使用ActiveX, Mozilla开发者将XMLHttp对象的主要方法和属性都复制到他们自己浏览器的XMLHttpRequest对象中。随着所有主流浏览器都对某种形式的XMLHttp提供支持,Ajax风格的界面开发迅速流行起来,诸如Opera、Safari的边缘浏览器软件也不得不支持某种形式的XMLHttp (均模仿Mozilla,选择在浏览器中实现XMLHttpRequest对象)。

真正的Ajax


尽管在Garrett的文章最后加了一些经常被问到的问题,但对于“Ajax到底是什么”仍然存在一些争议。简单地说,Ajax只不过是一种Web交互的方法。这种方法只是在客户端和服务器间传输少量的信息,从而给用户提供响应更及时的体验。

在传统的Web应用程序模型中,浏览器本身负责初始化向服务器的请求,以及处理来自服务器的响应,而Ajax模型不同,它提供了一个中间层(Garrett称之为Ajax引擎)来处理这种通信。Ajax引擎(Ajax engine)实际上只是一个JavaScript对象或函数,只有当信息必须从服务器上获得的时候才调用它。与传统的模型不同,不再需要为其他资源(诸如其他网页)提供链接,而是当需要调度和执行这些请求时,向Ajax引擎发出一个函数调用。这些请求都是异步完成的,也就意味着不必等收到响应之后就可以继续执行后续的代码。

服务器(传统模式中,它是提供HTML、图像、CSS或JavaScript)将配置为向Ajax引擎返回其可用的数据,这些数据可以是纯文本、XML或者需要的任何格式,唯一的要求就是Ajax引擎能够理解和翻译这种数据。

当Ajax引擎收到服务器响应时,将会触发一些操作,通常是完成数据解析,以及基于其所提供的数据对用户界面做一些修改。由于这个过程中传送的信息比传统的Web应用程序模型少得多,因此用户界面的更新速度将更快,用户也就能够更快地进行他们的工作。图1-1是在 Garrett文章中原图的基础上进行修改的,它说明了传统Web应用程序模型和Ajax模型之间的区别。

 

 

 

 

 Ajax的四个基本原则

 

 

1 浏览器中的是应用而不是内容

在传统的基于页面的Web应用中,浏览器扮演着哑终端的角色。它对用户处于操作流程哪一阶段一无所知。这些信息全部都保存在服务器上,确切地说,就是在用户会话上。时至今日,服务器端的用户会话早已是司空见惯。如果你使用Java或者.NET编程,服务器端的用户会话更是标准API的一部分——还有Request、Response、MIME类型——没有了它们简直不可想象。图1-11描绘了传统Web应用典型的生命周期。

当用户登录或者以其他方式初始化一个会话时,系统会创建几个服务器端的对象。例如,电子商务类型的网站需要创建表示购物车以及用户身份证明的对象。同时将浏览器站点的首页呈现给用户,这个HTML标记的数据流由模板文件以及特定于该用户的数据和内容(例如该用户最近浏览的商品列表)组成。

用户每次和服务器交互,都会获得另一个文档。在这个文档中,除了特定于该用户的数据以外,包含的其他模板文件和数据都是相同的。浏览器总是忠实地丢弃掉老的文档,显示新的文档,因为它是哑终端,而且也不知道还可以做些什么。

当用户选择退出或者关闭浏览器的时候,应用退出,会话消失。这个时候持久层会把用户下次登录后需要显示的信息存储起来。Ajax则不同,它把一部分应用逻辑从服务器端移到了浏览器端,图1-12描绘了这一情况。

图1-11  传统Web应用的生命周期。用户和应用会话的所有状态都保留在Web服务器上。用户在会话中看到的是一系列的页面,每次页面切换都不可避免地要到服务器上走一个来回

图1-12  Ajax应用的生命周期。用户登录后,服务器交付一个客户端应用给浏览器。这个应用可以独立处理很多的用户交互,对于自己无法独立处理的交互,应用会以后台方式发送请求给服务器,而不会打断用户的操作流程

用户登录的时候,服务器交付给浏览器一个复杂得多的文档,其中包含大量的JavaScript代码。这个文档将会在整个会话的生命周期内与用户相伴。在这一过程中,随着用户与其交互,它的外观可能会发生相当大的变化。它知道如何响应用户的输入,能够决定对于这些请求,是自行处理还是传递给Web服务器(Web服务器再去访问数据库或者其他资源),或者通过两者结合的方式进行处理。

因为这个文档在整个用户会话中都存在,所以它可以保存状态[8]。例如,购物车的内容可以保存在浏览器中而不是服务器的会话中。

2  服务器交付的是数据而不是内容

我们已经提到,在传统的Web应用中,服务器在每个步骤都需要把模板文件、内容和数据混合发送给浏览器。但实际上,当向购物车中添加一件物品的时候,服务器真正需要响应的仅仅是更新一下购物车中的价格。如图1-13所示,这只是整个文档中极小的一小部分。

基于Ajax的购物车可以向服务器发起一个异步请求来完成这件事,这样做显得更聪明。模板文件、导航列表和页面布局上的其他部分已经随着初始页面发送给了浏览器,服务器无需重发,以后每次只需要发送相关的数据就可以了。

Ajax应用可以通过多种方式来做这件事情。例如,返回一段JavaScript代码、一段纯文本或者一小段XML文档。这些方式各自的优缺点,我们将留到第5章再详细考察。但是,毫无疑问的是,无论返回数据采用何种格式,这些方式所传输的数据量都要比传统的Web应用中一股脑返回一个大杂烩的方式少得多。

在Ajax应用中,网络的通信流量主要是集中在加载的前期,无论如何,用户登录后是需要一次性地将一个大而复杂的客户端交付给浏览器。但是在此之后,与服务器的通信则会有效率得多。对于瞬态应用来说,积累起来的通信流量要比以前的基于页面的Web应用少很多。与此同时,平均的交互次数则有所增加。整体而言,Ajax应用的带宽消耗要比传统的Web应用低一些。

3 用户交互变得流畅而连续

浏览器提供了两种输入机制:超链接和HTML表单。

超链接可以在服务器上创建,并预加载指向动态服务器页面或者servlet的CGI参数。可以用图片或者CSS(层叠样式表)来装饰超链接,并且当鼠标停在上面时还可以提供基本的反馈。经过合理设计,超链接可以变成一个很有想像力的UI组件。

表单则提供了桌面应用的一组基础UI组件:输入文本框、单选按钮和多选按钮,还有下拉列表。但仍然缺少很多有用的UI组件,例如,没有可用的树控件、可编辑的栅格、组合输入框等。表单像超链接一样,也指向服务器的一个URL地址。

图1-13  细分服务器发送的内容,(A)是传统的Web应用,(B)是Ajax应用。(C)表示随着应用使用时间的延长,累积的网络流量的增长情况

超链接和表单也可以指向JavaScript函数。这一技术通常用在将数据提交给服务器之前对表单输入进行简单的校验,如检验是否有空值,数值是否越界等等。这些JavaScript函数的生存期和页面本身是一致的,当页面提交之后,这些函数也就不存在了。

当一个页面已提交而下一个页面还没有显示出来的时候,用户实际上处于没人管的状态。老的页面还要显示一会 儿,浏览器甚至还会允许用户点击一些链接。但这些点击可能会导致一些不可预料的结果,甚至破坏服务器端会话的状态。用户通常应该等到页面刷新完成,当然也 可以选择在刷新完成之前就在新页面上做一些操作。例如,当页面只显示了一部分时从中选择一条裤子放进购物车不大可能会造成什么破坏(例如,不会修改顶级的 服装分类:男装、女装、童装、配饰)。

我们继续看这个购物车的例子。Ajax的购物车是通过异步方式发送数据的,用户可以很快地把东西拖进来,就像点击一样快。只要客户端购物车的代码足够健壮,它可以很轻松地处理这样的负载,而用户则可以继续做他想做的事。

要 知道,在服务器端并没有一个真正的购物车等着装东西,只有会话中的一个对象而已。购物的时候,用户并不想知道会话对象,购物车对于用户而言是一个较恰当的 比喻,用现实世界中熟悉的概念来描述这里发生的事情。对于用户来说,如果强迫他们去理解计算机领域中的术语,只会让他们远离网站。等待页面的刷新,一下子 就把用户从愉快的使用体验中拽了出来,让他感觉到自己所面对的只不过是一台冰冷的机器罢了(图1-14)。使用Ajax来实现这些应用则可以避免这些令人不快的体验。当然了,在这个例子中的购物只是一个瞬态活动。考察一下其他的业务领域,例如,一个业务量很大的帮助中心或者一项复杂的工程任务,如果因为需要等待页面刷新而将工作流程打断几秒钟[9],那肯定是不可接受的。

图1-14  处理事件打断了用户的工作流程。用户要处理与业务相关的和与计算机相关的两种对象。这迫使用户频繁地在这两者之间切换,从而导致用户注意力分散,工作效率降低

Ajax的另一个好处是,我们可以对丰富的用户操作事件进行捕获。类似于拖拽这样的复杂UI概念也不再是遥不可及的。这使得Web应用的UI体验可以全面提升到近乎与桌面应用的UI组件相媲美的高度。从可用性的角度来看,这很重要,不仅仅是因为它释放了我们的想象力,而且也是因为它可以将用户交互和服务器端的请求更加充分地混合起来。

在传统的Web应用中,与服务器交互需要点击超链接或者提交表单,然后等待页面的刷新,这打断了用户的工作流程。与之相对应的是,让服务器响应鼠标移动、拖拽或者键盘输入这样的用户事件,也就是说,服务器在用户身边为用户服务,而不是挡在用户前面,打断他的操作。Google Suggest(www.google.com/webhp?complete=1)就是这样一个简单的但是很有说服力的例子。当用户在搜索框键入一些字符的时候,应用从服务器取回与用户已键入字符串相似的搜索条目(根据全世界其他人的搜索),并且显示在输入框下方的下拉列表中。

4  有纪律的严肃编程

现在传统的Web应用有时候也会用到JavaScript,不过主要是用来给页面添加一些花哨的东西。基于页面的模型使得这样的增强没有办法更进一步,限制了用户可以得到的更加理想的交互。这种类似于第22条军规的状况,使得JavaScript很不公平地获得了一种琐碎的、自由散漫的编程语言的名声,为那些严肃的开发者[10]所不屑。

为Ajax应 用编程的情况则完全不同。提交给用户运行的应用将会一直运行直到用户关闭程序为止。不崩溃,不变慢,也没有内存泄漏之类的毛病。如果我们的产品定位于独占 式应用的市场,这还意味着很多小时的密集使用。要达到这个目标,当然需要高性能的、可维护的代码,这与服务器端应用的要求是一致的。

相比之下,Ajax的代码库会比传统的Web应用大很多。对代码库进行良好的组织是非常重要的。编写代码不再是单个开发者的职责,而是整个团队来参与。可维护性、分离关注点、共同的编程风格以及设计模式,这些都是需要考虑的问题。

从某个角度来看,Ajax应用就是用户所使用的一块复杂的代码,它需要高效地与服务器进行通信。它显然来源于传统的基于页面的Web应用,但是它们之间的相似性也仅限于此,两者之间的差别就像是木马轮和现代自行车之间的差别。在脑海中要记得它们之间的这些差别,因为只有这样才能创造出真正引人注目的Web应用。

Ajax背后的技术

Garrett的文章中提到了几个他认为是Ajax解决方案组成部分的技术。它们包括:

☆ HTML/XHTML:主要的内容表示语言;

☆CSS:为XHTML提供文本格式定义;

☆DOM:对已载入的页面进行动态更新;

☆ XML:数据交换格式;

☆XSLT:将XML转换为XHTML(用CSS修饰其样式);

☆ XMLHttp:主要的通信代理;

☆JavaScript:用来编写Ajax引擎的脚本语言。

实际上,在Ajax解决方案中这些技术都是可用的,不过只有三种是必需的: HTML/XHTML、DOM以及 JavaScript。XHTML显然是显示信息所必需的,而DOM则是为了在不重新载入XHTML页面的前提下修改部分内容所必需的,最后的 JavaScript则是初始化客户端—服务器通信、操作DOM来更新网页所必需的。列表中的其他技术则对于微调Ajax解决方案很有用,但不是必需的。

在Garrett的文章中忽略了一个很重要的组件——必要的服务器端处理逻辑。前面列出的所有技术都与客户端的 Ajax引擎直接相关,但如果没有一个稳定、响应及时的服务器来向引擎发送内容,也就不会有Ajax的存在。为了实现这一目标,可以使用你所选择的应用服务器。不管你将服务器端组件编写为PHP页面、Java servlet还是.NET组件,都只需要确保向Ajax引擎发送的数据格式是正确的。



 
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/你好赵伟/article/detail/836756
推荐阅读
相关标签
  

闽ICP备14008679号