Ajax框架概述

Ajax框架介绍
　　到此为止，你可能已经注意到，使用Ajax编程时有很多麻烦事。如果你要支持多个浏览器（现在还有谁只支持一个浏览器呢？），无疑会遭遇不兼容问题。单看一个简单的动作，比如说创建XMLHttpRequest对象的一个实例，这需要先进行浏览器测试。一旦开始尝试使用Ajax技术，你很快就会注意到要反复地完成同样的一些任务。当然，你可以收集一些常用代码库，甚至创建自己的框架。不过，做这个工作之前，需要先了解一下现在已经有些什么了。
　　与所有优秀技术一样，Ajax已经催生出大量框架，有了这些框架，开发人员的日子好过多了。我们要强调一点，Ajax还很新，而且还在发展，框架领域也同样如此。几乎每天都有新来者，目前还看不出谁是最后的赢家。2003年6月之前，这方面的框架还不多，所以在以后的几个月可能还会有巨大变化。
　　有些框架基于客户端，有些基于服务器端；有些专门为特定语言设计，另外一些则与语言无关。其中绝大多数都有开源实现，但也有少数是专用的。我们不会面面俱到地谈到每一个框架，而且也不可能深入分析提到的每个框架。我们的出发点很明确，就是让你对现在有些什么有所认识。在你读到本附录时，我们提到的一些工具包可能已经销声匿迹，另外的则可能刚刚创建。哪个框架最适合你？对于这个问题，只有你自己有发言权；不过，在框架领域稳定之前，你可以持一种保守的态度。甚至还有人在着力将各种框架合并在一起，等这个工作结束时应该会有好戏看！当你读到本书时，情况应该会更加明朗，但也许你还想了解一下目前的情况 。
　　B.1　浏览器端框架
　　下面几节介绍了一些浏览器端框架。
　　B.1.1　Dojo
　　Dojo是最老的框架之一，于2004年9月开始开发。这个项目的目标是建立充分利用XHR的DHTML工具包，并把重心放在可用性问题上。Dojo只有几个文件，不用处理XHR的建立，只需调用bind方法，并传入想调用的URL和回调方法即可。就这么简单。还可以使用bind方法来提交整个表单。
　　Dojo有一个特性使它独树一帜，这就是它支持向后和向前按钮。尽管这个特性不一定在每个浏览器上都能用（遗憾的是，Safari就是一个异类），但你确实可以注册一个回调方法，在用户点击了向后按钮或向前按钮时触发这个方法。Dojo还提供了changeURL标记，力图解决使用Ajax所固有的书签问题。
　　Dojo看上去是相对成熟的工具包之一，它把重点放在可用性上，这一点很不错。Dojo表现得相当稳定，在它身后还有一些支撑力量。Dojo的邮件列表相当活跃，多看一些文档可能更有帮助。可以在dojotoolkit.org得到更多相关信息。
　　B.1.2　Rico
　　。更多有关的信息请访问qooxdoo.oss.schlund.de。
　　B.1.4　TIBET
　　你觉得Ajax最早是什么时候出现的？根据对此的解释，也许会认为TIBET可能是现存最老的框架。根据文档所述，TIBET小组从1997年就开始开发这个工具包，他们的目标是提供企业级Ajax支持。TIBET看上去不只是包装了XMLHttpRequest对象，它还对Web服务和底层协议提供了支持，并且提供了Google、Amazon和许多其他常用服务的预置包装器。
　　真正让TIBET卓而不群的是，它有一个完全交互式的基于浏览器的IDE，这能大大简化开发、调试和单元测试。更多有关的信息请访问www.technicalpursuit.com。
　　B.1.5　Flash/JavaScript集成包
　　在Ajax之前，Flash很是风行，很多Web网站都建立在Flash平台上。那些曾对Flash狠下一番功夫的人不想完全放弃Flash，利用这个开源项目就能同时利用Ajax技术。这个工具包在所有主要浏览器上都能用，使得JavaScript能够调用ActionScript，ActionScript也能调用JavaScript。可以来回传递大量对象，包括日期、串和数组。
　　Flash/JavaScript集成包的安装涉及一些JavaScript文件，以及两个用于Flash的库函数。从页面上调用ActionScript函数只需几行代码而已。有关的文档相当少，不过，如果你想使用Ajax访问Flash，这个工具包就很值得研究。更多有关的信息请访问weblogs.macromedia.
　　com/flashjavascript/。
　　B.1.6　Google AJAXSLT
　　基于Google Maps的工作，Google AJAXSLT是使用XPath的XSL转换（XSLT）的JavaScript实现。XSLT可以把XML文档转换为其他语言，如HTML。AJAXSLT允许使用JavaScript在浏览器上直接完成这些转换。
　　Google AJAXSLT在所有主要浏览器上都能工作，它是在BSD许可证下发布的。这个工具包很小，包括几个JavaScript文件，还有一些方便的测试页。Google AJAXSLT不是十全十美的，不过，如果Google Suggest有所提示，我们希望Google AJAXSLT的缺点能很快解决。因为Google是最先使用Ajax的网站之一，我们会很有兴致地看到在未来几个月它还会有所增加。更多有关的信息请访问goog-ajaxslt.sourceforge.net。
　　B.1.7　libXmlRequest
　　libXmlRequest框架也是比较老的一个框架，早在2003年就已经发布了。这个框架包括一个JavaScript文件，它相当于XMLHttpRequest对象的一个包装器，提供了两个重载的请求函数：getXml和postXml。另外，它有一些处理缓冲池和缓存的属性，还有一些工具函数处理常见的任务，如解析来自服务器的XML以及修改DOM。
　　这个工具包能在哪些浏览器上运行，这一点还不是很清楚，而且有关的文档相当少。这个工具包版权归其作者Stephen W. Cote所有，其中没有提到许可问题。因此，只能用它帮助你产生灵感。更多有关的信息请访问www.whitefrost.com/index.jsp。
　　B.1.8　RSLite
　　RSLite是远程脚本的一个实现，由Brent Ashley编写。从技术上讲，它没有利用作为Ajax核心的XMLHttpRequest对象，但是得到了更广泛的浏览器支持。如果你需要支持原来的浏览器，而这些浏览器不支持XMLHttpRequest对象，就可以试试RSLite。RSLite是相当轻量级的，已从2000年发展至今 。更多有关的信息请访www.ashleyit.com/rs/rslite/。
　　B.1.9　SACK
　　SACK（简单Ajax代码包）开发为一个瘦包装器，包装了XMLHttpRequest对象。其作者Gregory Wild-Smith认为，其他的许多框架太过复杂，而且做了许多本不该它们完成的任务。所以他创建了SACK来简化Ajax的开发。SACK包括几个可以简化服务器调用的方法。比起具体创建适当的XMLHttpRequest对象实例来说，用更少的代码就能向服务器发送数据，并处理响应。
　　SACK由一个JavaScript文件组成，其中包含很少的代码。SACK底层软件的发布得到了修改X11许可（也称为MIT许可），与大多数开源项目一样，它的文档并不多，不过，入门肯定还是绰绰有余的。SACK的真正强大之处在于它的简单性，如果你要找的是一个基本包装器，可以试试SACK。更多有关的信息请访问twilightuniverse.com/projects/sack/。
　　B.1.10　sarrisa
　　sarissa有一点是Ajax做不到的，它以一种独立于浏览器的方式对XML API提供了包装支持。利用这个框架，创建和使用XMLHttpRequest对象实在是小菜一碟（不用检查浏览器，它已经为你处理好了）。另外，sarissa还对使用DOM提供了支持。类似于Google AJAXSLT，sarissa也支持XSLT，它模拟了IE上的Mozilla处理器。
　　sarissa只包括几个类，在GPL协议下发布。Mozilla/Firefox和IE都充分支持sarissa，只在Opera、Konqueror和Safari浏览器上有些函数不能用。更多有关的信息请访问sarissa.
　　sourceforge.net/doc/。
　　B.1.11　XHConn
　　XHConn类似于SACK，它相当于XMLHttpRequest对象的一个简单包装器。你不用直接使用XMLHttpRequest对象，只需首先启动一个XHConn实例，与使用XHR同样的方法加以处理。也就是说，无需浏览器检查，并提供了一种简单的方法来确定浏览器是否支持XHR（这对于需要妥善降级的网站尤其方便）。
　　XHConn在Safari、IE、Mozilla、Firefox和Opera上都能工作。类似于大多数Ajax框架，这是一个开源实现，在Creative Commons License协议下发布。XHConn是一个代码不多的文件，不过它确实做到了该做的事情——简化Ajax。更多有关的信息请访问xkr.us/
　　code/javascript/XHConn/。
　　B.1.12　jquery
　　设计思想
　　简洁的思想：几乎所有操作都是以选择DOM元素（有强大的Selector）开始，然后是对其的操作（Chaining等特性）。
　　优点
　　小，压缩后代码只有20多k（无压缩代码94k）。
　　Selector和DOM操作的方便：jQuery的Selector与mootools的Element.Selectors.js比较，CSS Selector, XPath Selector（1.2后已删除）
　　Chaining：总是返回一个jQuery对象，可以连续操作。
　　文档的完整，易用性（每个API都有完整的例子，这是其它框架现在不能比的），而且网上还有很多其它的文档，书籍。
　　应用的广泛，包括google code也使用了jQuery。
　　B.2　服务器端框架
　　以下介绍服务器端的框架。
　　B.2.1　CPAINT
　　CPAINT（跨平台异步接口工具包）在服务器端实现Ajax，它向客户返回文本或DOM文档对象，以便用JavaScript处理。CPAINT在大多数主要浏览器上都能用，而且支持远程脚本，在GPL协议下发布。这个项目的文档相当完备，不过，CPAINT只支持PHP和ASP。更多有关的信息请访问sourceforge.net/projects/cpaint/。
　　B.2.2　Sajax
　　利用Sajax，可以直接从JavaScript调用服务器端代码。Sajax支持Perl、Python、Ruby和ASP等语言（不过奇怪的是，目前并不支持Java）。安装Sajax相当简单，只涉及针对特定服务器语言的简单的库。Sajax的开发社区极其活跃。已经确认的只有IE 6和Mozilla/Firefox提供Sajax支持，不过本书作者认为它在Safari上也能很好地使用。更多有关的信息请访问www.modernmethod.com/sajax。
　　B.2.3　JSON/JSON-RPC
　　JavaScript对象注解（JSON）是一种文本格式，与XML很相似，可以用于交换数据。JSON的设计要保证两方面，一方面便于人阅读，另一方面便于机器解析，它使用了C系列语言类似的约定。与JSON相关的还有JSON-RPC，这是一个远程过程调用（RPC）协议，类似于XML-RPC，但面向的是JSON语言。作为规约，JSON-RPC在许多语言中都有实现，包括Java、Ruby、Python和Perl。
　　由于JSON-RPC是规约，你需要知道哪个特定实现适用于你的环境，还要充分了解特定的实现。取决于具体的实现，有些实现的文档相当完备，有些则根本没有。开发人员的参与程度也有很大不同。关于JSON-RPC规约的讨论已经有些少了。更多有关的信息请访问 www.crockford.com/JSON/index.html。
　　B.2.4　Direct Web Remoting
　　利用Direct Web Remoting (DWR)，你能从JavaScript直接调用Java方法，就好像它们是浏览器的本地方法一样。尽管后台严格限制为Java，但DWR仍然是最流行的框架之一。DWR的文档是最棒的，还有一些有用的例子可以帮助你入门。
　　安装并不难，不过还要编辑Web应用的部署描述文件，另外要编辑DWR特定的文件。DWR配置文件指定了可以远程创建和调用的类，而且文档中警告用户：从浏览器调用服务器确实存在一些安全问题。除了包含服务器端代码的JAR文件，另外还有两个JavaScript文件包含了一些辅助函数。DWR适用于一些常见的Web框架，如Struts和Tapestry，在Apache协议下发布。如果想从Web页面调用Java方法，DWR能助你一臂之力。更多有关的信息请访问getahead.ltd.uk/dwr/index。
　　B.2.5　SWATO
　　Shift Web Applications TO (SWATO)也是一个基于Java的Ajax框架解决方案。SWATO在所有Servlet 2.3或更高版本的容器中都能工作，类似于DWR，它也需要对配置文件做一些更新。有意思的是，SWATO充分利用了JSON来完成客户和服务器之间数据的编组，与本附录中讨论的其他一些框架相似，它也允许从浏览器调用服务器端Java。为了帮助开发人员，SWATO包括许多可复用的组件，如自动完成文本框等。
　　与使用其他框架相比，使用SWATO要相对复杂一些，要访问的类需要实现一个SWATO接口。不过，其文档相当完备，对于入门来讲绰绰有余。SWATO设计为使用Spring来打包服务，但是不一定非得如此。更多有关的信息请访问https://swato.dev.java.net/doc/html/。
　　B.2.6　Java BluePrints
　　Sun的BluePrints小组一直忙于将Ajax纳入他们的解决方案目录（Solutions Catalog）中。Solutions Catalog包括一些很好的文档，描述了如何使用基本Ajax，如何实现自动完成，如何创建一个进度条以及如何验证表单。它还包括JavaServer Faces组件。为BluePrints Solutions Catalog开发的代码可以从www.java.net网站得到。
　　B.2.7　Ajax.Net
　　Ajax.Net之于Microsoft .NET就相当于SAJAX、DWR和SWATO之于Java。利用Ajax.Net，你能从JavaScript客户调用.NET方法。Ajax.Net包括一个DLL，可以与VB .NET或C#一同使用。Ajax.Net的文档很好地展示了针对各种场景的解决方案，而且能得到相关的源代码。不过，Ajax.Net的许可协议很不明确。更多有关的信息请访问ajax.net。
　　B.2.8　Microsoft的Atlas项目
　　Microsoft在Ajax领域涉足的时间已经不短了，毕竟，XMLHttpRequest对象是Microsoft发明的，而且从1998年开始就已经用在Web版本的Outlook中。Microsoft把重点放在提供一个更加健壮的开发环境上，从而让开发人员的工作更轻松。Microsoft的着眼点还不只这些，还力图提供客户端脚本框架、ASP.NET控件和Web服务集成。Microsoft还发布了Atlas项目，作为其ASP.NET 2.0预览版的一部分。有Microsoft的介入，开发人员的工具包可能会比今天充实得多。更多有关的信息请访问beta.asp.net/default.aspx?tabindex=7&t-
　　abid=47。
　　B.2.9　Ruby on Rails
　　Rails是一个令人兴奋的新Web框架，建立在Ruby语言基础上。如今，Rails已经得到了大量关注（在Google上查一下Rails，可以找到更多信息），这是因为使用Rails能够快速开发基于Web的应用。开发Basecamp时，37signals小组提出名为Rails的框架。Basecamp正是Ajax应用的主要示例，所以看到Rails对Ajax提供如此充分的支持，我们不应感到奇怪。Rails有许多内置的JavaScript库，其中包装了很多常用的特性，它还包含一个模块，其中包装了Ruby的JavaScript调用。如果你在使用Rails，就会发现Ajax非常简单。更多有关的信息请访问www.rubyonrails.org。

AJAX框架比较2009-12-09 17:58近两年来，AJAX之风愈演愈烈，其相关技术以及背后所秉承的理念正逐渐被越来越多的开发人员所认可。随之而来的AJAX开源框架也层出不穷。更 令人欣幸的是，在众多框架之中，我们华语开发者为Web应用开发人员贡献了两个出类拔萃之作：新技术的“领头羊”ZK，厚积薄发的“水牛 ”Buffalo。本期的工具栏目，邀请到ZK创始人——叶明宪和Buffalo创始人——陈金洲，对当前一些流行的AJAX框架做出点评，并且与读者分 享AJAX框架的发展现状及趋势。

--------------------------------------------------------------------------------
叶明宪观点

AJAX 已流行二、三年了，现今所谓 Web 2.0 网站或多或少有 AJAX 影子。然而新的 AJAX 框架仍不断诞生，现有的框架也在持续推出新的版本。为什么？

首先，AJAX应用范围持续扩大，从 del.icio.us 简易的编辑功能，到 999fang.com 整合 AJAX 和数据库搜寻，到 Google Spreadsheets 近似 Windows 应用程序。再者，AJAX已缓步进入企业应用。除了User Friendly，安全、开发及维护成本、与现有应用服务器、服务和开发环境的整合度等更是企业应用的重点。这些都已跳脱早期框架的范畴。

目前 AJAX 在企业应用正处于 Geoffrey Moore 所谓的Chasm中，预期接下二年会慢慢大量投入使用。而在消费型网站的应用正走过高成长期，聚光灯的焦点将逐渐移到如Google Spreadsheets的应用。

在这种背景之下，AJAX框架如雨后春笋，层出不穷。很多开发者朋可能都有自己的偏好，但是仍有一些开发人员面对这么多框架，可能会感觉无从下手。我们可以从多个面向来看这些框架。

从功能面来看，可分为以下几类：
1、浏览器端的底层链接库，如 Prototype, script.aculo.us, jQuery 等。
2、浏览器端UI组件库，如 Ext-JS, Dojo 等。
3、整合式框架，如 ZK, Backbase, IceFaces 等。
其中，底层链接库应用最广、轻巧易整合力但功能有限。整合式框架则包括浏览器端及服务器端的完整框架。DWR和GWT则较难分类。DWR基本是JavaScript-to-Java 的 RPC框架，而GWT则是在RPC 加上浏览器端开发工具。

从应用面来看，可粗分网站应用和企业应用。底层链接库多用于网站应用或当其它框架的基础。UI组件库则二者都有，而整合式框架侧重在企业应用。

从系统架构来看，可分Client-centric和Server-centric。所谓 Client-centric 是指你写的程序代码(UI部份)主要执行的地方在客户端 (即浏览器)，而 Server-centric 则在服务器端。大部份框架多是 Client-centric，如Dojo, Prototype，GWT，Ext-JS，Backbase等。而Server-centric则以ZK为代表。

一般读者不太注意架构的差别，但它是决定开发及维护成本的关键。

读到这里，可能仍有人心存疑问：到底哪种框架适合我的应用？事实上，没有单一个框架适合所有应用。对于强调简易直觉接口的Web 2.0网站而言，通常只有几个需要 AJAX化的功能，可藉由浏览器端的底层链接库的帮助，并投入相当资源，以使这些AJAX 化出众夺目才是最重要的。对于现有Web应用程序，如架构于Struts、JSP或JSF等，则可依其对JavaScript熟悉度而选择浏览器端UI组 件库或整合式框架。使用浏览器端 UI组件库，需要较多定制化JavaScript程序代码才能整合到原应用程序中。而使用整合式框架，则要视其是否支持现已使用的架构。例如，若使 用.NET平台，则只能使用 Microsoft的框架。若使用JSP则可使用ZK和Backbase。若使用JSF则可使用ZK，Backbase和IceFaces。

利用ZK框架设计的Web应用程序具备丰富的胖客户端特性和简单的设计模型。ZK包括一个基于AJAX可自动进行交互式操作的事件驱动引擎和 一套兼容 XUL (XML User-interface Language——基于XML的用户接口语言)的组件。利用直观的事件驱动模型，你可以用具有XUL特性的组件来表示你的应用程序并通过由用户触发的监 听事件来操作这些组件。目前，ZK 3.0 版本已发布。提供了基于XUL和XHTML现成丰富的组件：网格、标签页装饰器、树形目录、组合框、图表、滚动条、分割条、音频等等。此外，还提供了宏组 件，能够开发新组件像搭积木一样简单和方便。编写脚本(Script)功能可以用EL expressions和你偏好的脚本语言，包含但不仅限于Java、JavaScript、Ruby、Groovy和MVEL的语言。值得一提的是，最 新版本还集成了Google Maps, FCKeditor, Dojo以及 Timeline，并且提供对Google最新发布的手机操作平台Android的开发支持。

有人预测，Silverlight、 Flex等RIA框架的出现，将对AJAX框架构成严重威胁，我的看法刚好相反。Silverlight、Flex等是大型软件公司企图以私有 protocol 垄断新兴市场的老方法。然而因特网的巨大并不是任何人所能控制的。感谢Tim Berners-Lee等人无私的贡献，因特网已成为最公平最开放的平台了。事实上 Flex 不久前才刚转为 Open Source，这对定价超过一万美元的软件，算是个重大的挫败。

--------------------------------------------------------------------------------
陈金洲观点

毫无疑问，AJAX被越来越多的接受。这不仅仅体现在技术的应用上，更体现在行业范围内的需求提升上。Web应用这种类型不仅仅被用在企业业 务系统，更多被用在Web2.0应用中。这些应用意味着以前只能被几十人几百人使用的系统，突然之间会有几十万几百万的用户。用户有了更多选择，能够吸引 用户驻留的，除了华丽的界面，那么就是流畅的操作界面和快速的响应。作为实现不打断用户操作的关键技术AJAX, 从吸引用户这一点上，具有不可替代的使命。

意味着华丽、AJAX的Web2.0应用同样也冲击着企业应用的需求。虽然没有统计数据，但可以看到越来越多的企业应用要求更直观的界面，更 流畅的操作，更少的延迟。例如，在前两年，级联下拉框的实现，大多数的框架（或者应用）的实现是选中一个时刷新整个页面，然后根据选中的那个更新下一个下 拉框的待选值列表。这个实现在今天看起来几乎是完全不可接受的，无论对客户还是对开发者。

开发者这边，去年还有关于AJAX几宗罪的讨论，然而现在看来，更多的讨论沉浸到了某一个具体技术中。在认清AJAX技术本质之后，更多的开 发者或欣然接受，或用户要求，开始了AJAX相关技术的学习和使用。从我周围看来，曾经认为JavaScript是不太入流的语言的程序员，现在已然逐渐 发现，JavaScript很有趣，很强大；用 JavaScript实现很酷的网页效果，很有成就感，等等。

另外， AJAX这个词本身，早已远远超越了它所代表的本来含义。AJAX原本是异步的JavaScript和XML。然而一看到一个绚丽的网页（Web应用）， 几乎大多数人，具备Web相关知识的，第一个问题往往是：这用的AJAX吧？──AJAX现在几乎成为圆角、拖拽、绚丽、无刷新的代名词。当一个名称上升 为一种概念、一种直觉的时候，我们应该知道，相关的技术应用到了什么程度。

现在几乎已经没有人手工与XMLHttp对象打交道，绝大多数的开发者都使用Buffalo, DWR, Prototype等辅助库、框架进行开发。

AJAX框架的选择

由于现在很少有人只用一种AJAX技术，我将AJAX框架的范围扩大一些，分为偏重展现、偏重传输、工具型三个部分。由于我自己的Web工作 语言主要在 Java, Ruby以及Python之间，以下的评价不包含PHP, .NET下的一些工具。另外，对自己开发的和它的主要竞争者DWR有主要的比较，其他的仅作泛泛评述，估妄言之。

偏重展现：YUI, Qooxdoo, Dojo
·YUI ：目前设计比较完整，美观，全面的界面工具库。
·Qooxdoo: 开源的另一种选择。
·Dojo: 比较完善的库结构，丰富的界面控件。

偏重传输：Buffalo, DWR
Buffalo特性：
1、基于prototype。如果你的AJAX应用也是基于prototype，那么可以减少重复加载prototype的带宽，并且获得相当一致的编程概念。
2、Bind: 提供了对结果数据的处理，直接将数据绑定到页面对象并展示，这是一个动人的特性。在2.0中，Bind能力更加强大，能够将值直接绑定到表单元素、表格、 DIV/Span、甚至整个表单上。关键是这种绑定是无侵入并且与buffalo整体结构完全整合，对外表现只有一个简单的 {{buffalo.bindReply}}或者{{Buffalo.Bind.bind}}即可。
3、序列化：Buffalo支持任意对象，任意深度，任意数据结构的Java到JavaScript以及JavaScript到Java的双向序列化，并且支持引用。
4、生命周期对象访问：1.2.4之前需要继承一个BuffaloService,从1.2.4开始就不需要继承了，引入了线程安全的 BuffaloContext对象，只需要通过BuffaloContext.getContext()即可获得一个线程安全的引用，并且对 Request的各种属性进行操作。
5、对Collection/Array的模糊处理：Buffalo中提供了对Collection/Array对象的模糊识别能力。例如：服务器端有一个方法需要List参数，客户端传递过去一个javascript数组就可以了，不需要费心的组装对象。
6、客户端组装对象：Buffalo支持在客户端组装对象，甚至可以直接将整个表单序列化为一个对象作为参数传给远程客户端。
7、对重载方法的处理能力：由于Java与JavaScript之间类型的不匹配，DWR的代码生成无法对重载方法进行处理。例 如，sum(double,double), sum(int, int) DWR很可能不知道你要调用哪一个。从2.0开始Buffalo支持了对重载的处理。

DWR特性：
1、支持Batch，可以将多个Service函数调用放在一个XMLHttpRequest请求中完成。
2、Converter：可以转换任意类型的Java对象到JavaScript，并允许直接使用。例如：Customer类包含一个 address变量，当AjaxCall返回Customer对象的时候，可以直接在Javascript中使用customer.address来获得 Address的信息。
3、允许Expose部分函数和属性。（Buffalo无限制，可以访问Service中的任意函数。）
4、DWR2.0中提出了Reverse Ajax，提供在Java代码中来处理页面上元素的功能。

工具型：Prototype, JQuery, Dojo
·Prototype：得益于Ruby语言的设计，它使得你能够以几乎类似于编写Ruby的方式编写JavaScript。由于绑定在 Ruby On Rails的发行包中，它成为近两年最流行的AJAX工具。早期它小巧灵活，现在由于加入太多的特性，日渐臃肿。目前1.6版本大小已经超过120K。
·JQuery：Prototype的主要竞争者。简单是它最大的优点。大多数常见的复杂操作、效果，JQuery的代码量能够比Prototype少50%以上。
·Dojo：采用类似于Java包的管理方式，实现按需加载JS。提供了全面的AJAX、DOM操作支持。然而需要在HTML TAG中嵌入额外的属性，使得网页不能遵守W3C标准，不少开发者对此耿耿于怀。

来自RIA框架的冲击？

我并不赞同这种说法，恰恰相反，我认为像Silverlight，Flex等这些RIA框架要考虑来自Web应用的冲击。Web领域几乎已经 不存在技术壁垒，能做哪些，那些不适合，负载均衡等等已经有充分的资源可以参考。各种模式都可以灵活的应用到其中，各种测试工具（如Selenium网页 测试工具）、开发工具支持得非常出色。而RIA框架要考虑的问题远远要比现在的Web应用多得多。除了RIA所承诺的更容易的实现华丽的效果──在多种 JS库的支持下这些效果在Web下并非难事──他们有更多的问题需要考虑：资源的获取和释放，测试的支持，本地存储的问题，事件机制，状态的同步，客户 机、服务器数据交互机制（序列化反序列化）等等。RIA想如同现在的Web应用般大规模，远不到时候。大多数基于RIA应用的考虑是让应用能够离线运行， 然而与此同时浏览器也在发展，基于网页的本地存贮已经在Google Reader中可以实际使用。也许某一天浏览器就是一个完美的RIA平台，Web应用只需添加本地存贮支持就可以离线使用──类似于Flex、 Silverlight的RIA技术，与Web应用，哪个更容易被接受，还真难见分晓。

经验介绍
http://developer.51cto.com 2009-08-18 09:17 佚名 javaeye 我要评论()

这里介绍AJAX框架的经验介绍，包括AJAX是WEB2.0的基石，现在网上流行几种开源的AJAX框架，DWR和Buffalo都是Web Remoting框架，区别在于。
AJAX是WEB2.0的基石，现在网上流行几种开源的AJAX框架，比如：jQuery,Mootools,Dojo,Ext JS等等。

让我们来看看选择AJAX框架的基础：
◆你的项目需求（即你需要哪些特性，例如是否要求做出精美的界面、特效或其它功能）
◆是否支持A等级的浏览器（IE, Firefox等）?
◆文档的质量：是否完善（包含教程，API，代码示例等）
◆框架的可扩展性如何？为框架写插件容易吗？
◆你是否喜欢它的API的风格？
◆能大多程度上统一你的JavaScript代码的风格？
◆框架大小（太大的框架导致用户下载时间的延长）
◆框架是否强迫你改变写HTML的方式（Dojo就是这样）？
◆代码执行速度：性能如何？
◆代码是否为模块化（Mootools为高度模块化）？代码可重用性如何？

Tacos类包项目为Tapestry Web框架提供一些高性能的组件,同时也为在页面或自己组件中使用的AJAX框架(它当前支持的框架主要是dojo但也支持Prototype，script.aculo.us ，Rico)提供服务端Java支持。

HTMLi - 100% XSL AJAX框架，可与Java,ASP,PHP等集成使用。可自由扩展与定制。支持多种CSS样式。HTMLi提供了一些我们经常要用到的AJAX UI组件如：datepicker、Menu Bar、Progress Bar、Splitter、Status Bar、TabPane、Tree、windows等。

jMaki是SUN支持的一个AJAX框架。这个项目的是让Java开发人员在其基于Java的应用程序中(不管是JSP标签库还是JSF组件)都能使用AJAX技术。jMaki使用了Java与JavaScript中最优秀的部分以此来提供一些Rich AJAX style widgets。jMaki当前提供的bootstrap widget是来自Dojo,Scriptaculus,Yahoo UI Widgets,Spry,DHTML Goodies,和Google等组件库。jMaki提供为这些widget组件库提供了一个公共接口以便让你可以在同一页面中一起使用这些组件库。如果你有兴趣利用jMaki项目来快速开发Web应用程序，可以使用NetBeans 5.5的jMaki插件。这个插件可以直接把jMaki组件拖放到JSP页面中。

BZByte EZAjax是一个开源的Ajax Web框架。BZByte Ajax框架采用服务器端的Java来创建DOM而不是通过web浏览器的JavaScript。该框架的所有更新都是GUI驱动，所以无需担心暴露应用程序的代码和远程接口。GUI更新快速并且不依赖终端用户计算机的快慢。

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的支持，缺点是库目前还是不是很全，功能也不强大。

国产框架参考：龙博AJAX:http://www.longboo.com