Ajax开发小结&慎用AJAX框架

第一篇：Ajax开发小结

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这个技术门槛。sf上的ZK似乎也不错，但是带来的是xul这个技术门槛，同时后台被绑定在了J2EE服务器上面。

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。” , 如果客户端不是简体中文版的系统的时候就判断不到了。其实这个地方只要有异常，都必须走异常处理流程了，不用区分的那么仔细。
原文地址：http://www.blogjava.net/emu/archive/2005/11/22/20888.html

 

第二篇：某知名大企业的教训–慎用AJAX框架

从年初到现在，AJAX之风预演愈烈，尤其是在国内，大多是一片叫好的声音。目前好像很多人都在搞基于AJAX的框架，国外也有一些都已经发布。对于这种一直都存在技术，Google、微软一造势，大家的热度好像有点过了头。看来现在咱们这些程序员真的都是些追星族啊！

   难到AJAX真的就那么优秀，值得提升到框架的高度，让系统UI端围着它转？单纯从AJAX本身来说，其最主要不过就是解决在网页上一个无刷新获取数据的 问题，再加上减少了数据的传输量，将数据解析的工作推到了客户端，的确能解决很多传统的问题，很方便的实现一些动态效果。然而，要围绕AJAX建立一个框架，通过AJAX完成UI端绝大部分内容的展现，我个人认为却是欠妥。现在很多人在网站上说，AJAX多多成熟，能达到多好多好的效果，但是问题是，AJAX技术本身成熟，但AJAX框架却是十分的不成熟。

   笔者前一段一直在参与一个国外知名大公司的一个产品的开发，这套系统好几年前就开始做了，系统的UI很多是基于AJAX的，对AJAX的应用可谓登峰造极（当然，那个时候肯定还没有AJAX这个名词），其界面的可操作行几乎可与桌面系统媲美。这系统有一个强大的AJAX框架，光是相关基础JS文件就是数十个，整个UI基于Javascript事件驱动，数据由XMLHttp获取。整个方案看上去的确很棒，或许正是现在很多人想要实现的。但实际情况是如何呢？效果是实现了，程序开发和测试、维护的效率则是大大的下降了。开发就不说了，前期投入巨大，系统复杂性剧增，程序也只能用IE访问。测试的时候这边 AJAX的javascript的bug满天飞，那边调试这种错误极不方便，没有好的JS的调试器，更看不到实际输出的html代码。维护那就糟糕，加个新功能，JSP文件、标签、JS、后台类全要过一遍。或许正是这些不易克服的问题，我看到在最近开发的配套软件里，就基本没有用什么AJAX了。

   大公司的尝试和经验，或许能给大家一些启示。说到底，所有的技术都是有利有弊的，AJAX也是一样。我个人认为AJAX 最适合的就是Google Map这种网上地图系统，展现方案相对比较单一，又非常的需要无刷新的获取数据。对于那些业务比较多，展现风格非常多样的业务系统，万万不可脑子一热，真的要用什么AJAX框架，到头了只回为了一点无谓的效果砸了自己的脚。

   最后强调一下，AJAX是个好东西，在项目里用它来实现一些辅助效果（最传统的比如用户输入数据时实时的验证，给出相关提示）即快捷又神奇，但过度使用很 容易让自己系统陷入麻烦之中，一定要慎重！此外目前公布出来的所谓的那些AJAX框架大多都是实现一个Form或者一部分页面的无刷新取数，根本谈不上什 么Web框架，目前没必要抱太大的希望。最近down了几个开源的ajax的东西看了看，觉得对一般开发人员来说，ajaxtags (http://sourceforge.net/projects/ajaxtags/) 是个不错的东东，简单易懂，可以仿照它的标签做一些自己的实现，值得看一看。
原文地址：http://www.blogjava.net/weidy/archive/2005/11/25/21451.html

<script type="text/javascript"><!--google_ad_client = "pub-3123320833494633";google_ad_width = 728;google_ad_height = 90;google_ad_format = "728x90_as";google_ad_type = "text_image";google_ad_channel ="";//--></script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>