Ajax应用场景

Ajax应用场景

　　一、适用场景

　　表单驱动的交互

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

　　深层次的树的导航

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

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

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

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

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

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

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

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

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

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

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

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

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

　　二、不适用场景

　　部分简单的表单

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

　　搜索

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

　　基本的导航

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

　　替换大量的文本

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

　　对呈现的操纵

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

　　存在的问题

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

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

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