Ajax技术全解之三

Ajax适用场景

1.表单驱动的交互

传统的表单提交，在文本框输入内容后，点击按钮，后台处理完毕后，页面刷新，再回头检查是否刷新结果正确。使用Ajax，在点击sunmit按钮后，立刻进行异步处理，并在页面上快速显示了更新后的结果，这里没有整个页面刷新的问题。

2.深层次的树的导航

深层次的级联菜单（树）的遍历是一项非常复杂的任务，使用JavaScript来控制显示逻辑，使用Ajax延迟加载更深层次的数据可以有效的减轻服务器的负担。



 

我们以前的对级联菜单的处理多数是这样的：

为了避免每次对菜单的操作引起的重载页面，不采用每次调用后台的方式，而是一次性将级联菜单的所有数据全部读取出来并写入数组，然后根据用户的操作用 JavaScript来控制它的子集项目的呈现，这样虽然解决了操作响应速度、不重载页面以及避免向服务器频繁发送请求的问题，但是如果用户不对菜单进行 操作或只对菜单中的一部分进行操作的话，那读取的数据中的一部分就会成为冗余数据而浪费用户的资源，特别是在菜单结构复杂、数据量大的情况下（比如菜单有 很多级、每一级菜又有上百个项目），这种弊端就更为突出。

如果在此案中应用Ajax后，结果就会有所改观：

在初始化页面时我们只读出它的第一级的所有数据并显示，在用户操作一级菜单其中一项时，会通过Ajax向后台请求当前一级项目所属的二级子菜单的所有数据，如 果再继续请求已经呈现的二级菜单中的一项时，再向后面请求所操作二级菜单项对应的所有三级菜单的所有数据，以此类推……这样，用什么就取什么、用多少就取 多少，就不会有数据的冗余和浪费，减少了数据下载总量，而且更新页面时不用重载全部内容，只更新需要更新的那部分即可，相对于后台处理并重载的方式缩短了 用户等待时间，也把对资源的浪费降到最低。

3.快速的用户与用户间的交流响应

在众多人参与的交流讨论的场景下，最不爽的事情就是让用户一遍又一遍刷新页面以便知道是否有新的讨论出现。新的回复应该以最快的速度显示出来，而把用户从分神的刷新中解脱出来，Ajax是最好的选择。

4.类似投票、yes/no等无关痛痒的场景

对于类似这样的场景中，如果提交过程需要达到40秒，很多的用户就会直接忽略过去而不会参与，但是Ajax可以把时间控制在1秒之内，从而更多的用户会加入进来。

5.对数据进行过滤和操纵相关数据的场景

对数据使用过滤器，按照时间排序，或者按照时间和名称排序，开关过滤器等等。任何要求具备很高交互性数据操纵的场合都应该用JavaScript，而不是用一系列的服务器请求来完成。在每次数据更新后，再对其进行查找和处理需要耗费较多的时间，而Ajax可以加速这个过程。

6.普通的文本输入提示和自动完成的场景

在文本框等输入表单中给予输入提示，或者自动完成，可以有效的改善用户体验，尤其是那些自动完成的数据可能来自于服务器端的场合，Ajax是很好的选择。

Ajax不适用场景

1.部分简单的表单

虽然表单提交可以从Ajax获取最大的益处，但一个简单的评论表单极少能从Ajax得到什么明显的改善。而一些较少用到的表单提交，Ajax则帮不上什么忙。

2.搜索

有些使用了Ajax的搜索引擎如Start.com和Live.com不允许使用浏览器的后退按钮来查看前一次搜索的结果，这对已经养成搜索习惯的用户来说是不可原谅的。

现在Dojo通过iframe来解决这个问题。

3.基本的导航

使用Ajax来做站点内的导航是一个坏主意，为什么不把时间放在让系统程序作的更好上呢？

4.替换大量的文本

使用Ajax可以实现页面的局部刷新，但是如果页面的每个部分都改变了，为什么不重新做一次服务器请求呢？

5.对呈现的操纵

Ajax看起来像是一个纯粹的UI技术，但事实上它不是。它实际上是一个数据同步、操纵和传输的技术。对于可维护的干净的web应用，不使用Ajax来控制页面呈现是一个不错的主意。JavaScript可以很简单的处理XHMTL/HTML/DOM，使用CSS规则就可以很好的表达数据显示。

存在的问题

1.用JavaScript作的Ajax引擎，JavaScript的兼容性和DeBug都是让人头痛的事；

2.Ajax的无刷新重载，由于页面的变化没有刷新重载那么明显，所以容易给用户带来困扰?D?D用户不太清楚现在的数据是新的还是已经更新过的；现有的解决有：在相关位置提示、数据更新的区域设计得比较明显、数据更新后给用户提示等；

3.中间过程不能被bookmark。解决方法：GoogleMaps通过在页面上提供一个”link to this page”的办法来解决。另外，还可以通过url链接中加无效的?^标记来解决，但还未验证。

AJAX框架 

DWR - Web Remoting 
Buffalo - Web Remoting (based on prototype) 
prototype - JS OO library 
openrico - JS UI component (based on prototype) 
dojo - JS library and UI component 
qooxdoo - JS UI component (C/S Style) 
YUL - JS UI component 
Web Remoting - DWR vs Buffalo 

DWR和Buffalo都是Web Remoting框架，区别在于： 

DWR使用自定义的简单文本协议，而Buffalo使用burlap协议。因此Buffalo解析大数据量可能会比较慢，然而可以适用于多种服务器端和客户端，并且burlap协议的完整性和支持的数据类型更加丰富 
Buffalo基于prototype，如果你的AJAX应用也是基于prototype，那么可以减少重复加载prototype的带宽，并且获得相当一致的编程概念 
DWR的服务器端实现要比Buffalo完善一些 
DWR更加通用一些，用户比较广，而Buffalo是国内的Michael写的，用户使用比较少(名气较小) 
建议使用buffalo，相对更加易用，然而服务器端功能有待完善 
JavaScript Component Library - prototype vs qooxdoo vs dojo vs YUL 

prototype是一个非常优雅的JS库，定义了JS的面向对象扩展，DOM操作API，事件等等，之上还有rico/script.aculo.us实现一些JS组件功能和效果(不过目前还不是很完善)，以prototype为核心，形成了一个外围的各种各样的JS扩展库，是相当有前途的JS底层框架，值得推荐，prototype以及rico/script.aculo.us的一个特出特点就是非常易学易用，门槛很低，常常是一两行JS代码就可以搞定一个相关的功能。同时它也是RoR集成的AJAX JS库。 
qooxdoo是一个功能很强的JS组件库，完全模仿Windows操作系统的GUI组件。特点是不通过常规的HTML来构造页面，完全使用JS以类似VB/Delphi风格的编程方式构造Web GUI界面，比较适合内网面向C/S风格的web应用，，而不适合面向Internet的界面多变风格的应用。qooxdoo的一个重大卖点在于qooxdoo将要提供一个FormDesigner的IDE，通过在IDE里面的可视化拖拽设计方式来自动生成C/S风格的web页面js代码。qooxdoo缺点是JS文件体积过大，超过200KB，初次下载会比较慢，而且并不适合Internet消费类网站。 
dojo是一个各个方面相当完善的JS库，包括了JS本身的语言扩展，以及各个方面的工具类库，和比较完善的UI组件库，也被广泛应用在很多项目中，他的UI组件的特点是通过给html标签增加tag的方式进行扩展，而不是通过写JS来生成，dojo的API模仿Java类库的组织方式。dojo的优点就是库相当完善，发展时间也比较长，缺点是文件体积也比较大，200多KB，初次下载相当慢，此外，dojo的类库使用显得不是那么易用，至少给我的感觉是相当笨拙，特别是和prototype相比，更加显得难用。 
YUL是Yahoo新近发布的AJAX组件库，也是一个包含了各个方面，从工具类库到通讯，到UI组件的综合性JS库。YUL的优势在于文档非常齐全，而且有Yahoo的支持，缺点是库目前还是不是很全，功能也不强大。