1 AJAX还是AJAH
* AJAX的很多经典应用其实都是利用xmlhttp空间访问后台程序,后台程序返回脚本用eval回调或者返回简单数据的方式来开发。这样的开发模式的好 处是设计简单轻巧,对熟悉dhtml的开发者来说上手会比较块,跨浏览器问题也容易解决,做简单的应用也够用。gmail,google suggest都是用这种方式。但是在我看来gmail已经吧AJAH应用到极限了,更复杂的数据结构用简单数据和回调方式来组织就开始有点力不从心了。
* 前AJAX的一种传统做法是后台返回完整的xml文件后用脚本(利用控件)解析xml后操作页面的dom节点来动态生成页面的一部分。这样作的优点是可以 充分利用xml的强大表达能力传输各种数据结构,缺点是页面的dom操作效率不高,而且IE在dom操作的API上bug多多。之所以叫“前AJAX”, 因为我们在AJAX这个名词出现前已经这样做了很多年了。
* AJAX另一种传统做法是后台返回完整的xml文件后用脚本(利用控件)解析xml后生成html代码再灌回页面的层中。这样的做法回避了页面dom操作 的一些问题,在生成的内容比较多的时候利用一些字符串计算的优化技巧(主要是数组和正则的应用)可以相当高效的生成页面。在我看来这是未来的发展趋势。
我 现在的项目主要采用的是第三种方式,结合第二种。我使用的是自己的一个小巧的框架,模拟jsp的语法来生成html代码,但是依赖于浏览器的xml解析 API,因此难以跨浏览器。google的开源项目ajaxslt提供了一个纯js的xslt解决方式,功能更强大,可以在页面中局部的应用xslt解析 xml生成html或者其他形式的数据,但是带来了xslt这个技术门槛。
2 CACHE
如果使用xmlhttp控件,在发起http请求的时候IE会包办cache策略,很多时候更新了数据却无法获得更新后的数据。一开始试图用传统方式在URL后面加随机数来强制更新,但是IE仍然距不发出新的请求。
一个解决方法是在后台写expires: 0或者其他的禁止前台cache的头,但是这样在数据没有更新的时候又会带来不必要的服务器压力、响应延迟和带宽浪费。
一个稍微好一点的解决方法是,前台在提交数据以后,需要强制更新数据的时候:
xmlhttp.setRequestHeader("If-Modified-Since","0");
3 系统错误: -1072896748。
用xmlhttp 接收到数据的时候经常是用xmldom.loadXML(xmlhttp.responseXML.xml)来判断返回的数据的正确性,但是如果后台送过 来不正确的xml的时候有时回触发-1072896748系统错误。这是因为xmlhttp.responseXML已经没有解析到东西了,我们还试图访 问它的xml属性而触发的。
解决的方法是在使用responseXML.xml 或者 responseText的时候要做try/catch:
try{var tmp = xmlhttp.responseXML.xml}catch(ex){err=true;}
有些人喜欢catch的时候判断 exception.description=="系统错误: -1072896748。" , 如果客户端不是简体中文版的系统的时候就判断不到了。其实这个地方只要有异常,都必须走异常处理流程了,不用区分的那么仔细。