buffalo 2.0 最终版正式发布
[Update] InfoQ中文报道：
http://www.infoq.com/cn/news/2007/04/ajax-framework-buffalo2
从2.0-alpha1发布至今，经过长达半年多的测试阶段，buffalo 2.0正式版本发布。2.0最大的关注点在于性能的提升和完全自行实现的java到javascript协议转换。根据评测，2.0版本要比前一阶段版本最高提升30%性能。这得益于新的协议实现以及为大规模AJAX调用而进行的优化。
对于一直使用alpha版本的用户，此次升级很简单，只需要将相应的jar和js进行替换即可。从1.2.x版本升级的用户，升级也很简单：
* 删除所有burlap*.jar, buffalo*.jar, 替换为buffalo.jar
* 替换新的buffalo.js
* 将继承自BuffaloService的类，对session等信息的使用替换为对RequestContext.getContext().getXXX的使用。（注意，目前有开发者报告在resin 2.1服务器上偶尔会出现丢session的现象）
2.0正式版本的发布意味着完全自我独立的协议实现，为后续特性的开发打下了基础。
继续感谢：一直使用、提出Bug以及解决办法、在论坛帮助他人的朋友们，没有你们，buffalo无法走到今天。
buffalo 2.0-alpha1 released
没什么可说的了，从2005年4月至今，buffalo走过了1.0, 1.1, 1.2到现在的2.0
最大的改变是彻底抛弃了burlap，新的协议以及实现完全重新编写（相当于一个定制的xml pull parser）速度相当快，几乎接近于纯文本的处理速度。另外的改变是为了适应项目国际化以及更好的代码环境，buffalo从java.net迁移到了sourceforge，并且使用maven作为项目管理工具。另外，修复了若干bug。
完整的特征列表如下：
* 支持方法重载
* 重新实现协议，更好的解析和缓存，效率比1.2.x系列提升30%
* onTimeout和onException事件支持
* 更友好的错误信息显示
* 代码库迁移到sourceforge，采用subversion
* 采用maven管理项目
下载地址：
* http://buffalo.sourceforge.net
* 下载2.0alpha1
这个版本的推出主要是为了检验新的协议解析器，有任何问题请到buffalo论坛进行讨论。2.0正式版的发布将主要取决与文档的完善情况。
Buffalo 2 vs Buffalo 1: +30% performance
说明：测试机器配置：笔记本Pentium M 2.0G, 2G内存。第一列是循环调用次数；Request / Second是每秒能够处理的请求数（吞吐量）。由于新的实现加入了众多缓存，因此在小数量调用时不能体现优势，但真正在高并发请求的场景中，2要比1.2提高30%的性能。在运行Demo应用时，明显感觉速度有所提高
buffalo2.0的发布时间还没有确定，需要试验的请通过cvs获取。另外，我很想与DWR的处理速度进行一个对比，但仔细看了DWR代码，代码写的与servlet api太紧，很难单独抽出来进行测试。哪位有相关数据的请给我帮助。
正本清源：所谓Ajax输出的三种形式
QuirksBlog: The AJAX response: XML, HTML, or JSON?
说实话，我没想到Bing Ran会问我这个问题。早先这篇文章在TSS上贴出的时候，我很快的浏览，便一眼看出这篇文章作者所处的角度。事实上，AJAX概念的不完整和不严密性 ——异步的JavaScript + XML——导致作者将AJAX的输出分为三种类型：XML, HTML片断和JSON对象字符串。
首先看XML。对于RPC的数据传输，XML从来都是当仁不二的选择。对于将对象序列化为XML字符串的方式，往往有两种选择，一种是将对象本身的属性作为节点进行输出，一种是利用语言的元数据特性进行序列化输出。两者存在较大不同。对于第一种，输出案例如下：
<books>
<book>
<title>JavaScript, the Definitive Guide</title>
<publisher>O’Reilly</publisher>
<author>David Flanagan</author>
<cover src="/images/cover_defguide.jpg" />
[...]
Ajax/Amowa框架Buffalo 1.2发布！
经过长时间的工作和buffalo社区的支持，buffalo ajax/amowa framework 1.2发布。新版本包含了经过改进激动人心的Spring集成，Prototype集成，以及浏览器前进后退的支持。主要的新特性如下：
* 支持浏览器前进后退（这个特性几乎可以在小型应用中替换MVC）
* 重写了整个服务调用模块
* 重写了Spring集成代码，集成Spring更加容易
* 重写了burlap的依赖，移除了特定版本的burlap-fix.jar。无需任何变动，现在可以在resin app server中使用buffalo了。
Buffalo Ajax/Amowa Framework是一个全新的远程调用/Web框架。他可以向JSON/DWR一样，被应用为一个web远程调用框架，简化web客户端与服务器端的调用（buffalo的API更加简单！）；也可以在小型应用中承担页面切换的任务，基于OPOA的概念，让buffalo为你管理页面切换；在大型应用中，buffalo也可以在其中承担页面无刷新获取数据的工作。Buffalo binding组件能够一致性地将数据绑定到html组件上，也可以绑定到JavaScript Template的模版上。目前已经有若干真正的商业应用在不同层面应用了buffalo。在这个版本中，buffalo提供了全面的文档，丰富的发行包，成熟的Demo，buffalo已经为企业应用作了充分的准备。
Buffalo站点：http://www.amowa.net/buffalo/
演示：http://demo.amowa.net/buffalo-demo/index.jsp
下载：http://www.amowa.net/buffalo/index.html?page=download
为什么我不公布buffalo roadmap
江南白衣-拾豆豆 说:
恭喜恭喜，开源软件能坚持做下来的在中国不多阿
Michael – Buffalo 1.2alpha1发布 说:
是啊
江南白衣-拾豆豆 说:
下一站 Page Framework 的roadmap哪里能看到？
Michael – Buffalo 1.2alpha1发布 说:
不敢发布，怕伤害等待的人……
这是真的。毕竟国内做开源能坚持下来的，太少了。我们有很多的热情、创意与想法在一瞬间爆发，做成开源项目，在还没有来得及热起来的时候就迅速的冷却下去。scud:你今天框架了吗？描述了这样一种现状。管理课上，我学到了张瑞敏的一句话：把简单的事情做好就是不简单，把平凡的事情做好就是不平凡。显然，所有的项目刚出来的时候都是新的，随着进展，琐碎的事情越来越多，也就有越来越多的理由与借口来放弃这个项目。我看到很多的优秀的项目都不断的诞生与消亡，归根结底，我宁愿相信，这是一个态度问题，而并非技术问题。
我不知道buffalo最后会怎样，但是从目前得到的评价，基本上正面的居多：发给java.net，他们说very interesting, 并且随时欢迎加入他们的community, 然而由于不能提供svn服务，只得作罢；Shane也表示，当buffalo代码复杂度达到一定规模的时候可以帮助将项目放到codehaus。同时Buffalo论坛上也有一群热心的朋友帮助使用测试评估。这些都是莫大的鼓舞。从行业趋势来说，用户体验、Web2.0, Ajax无疑是今年最hot的词。有理由相信，buffalo能够在若干方面真正对用户与程序员都具备益处。
然而buffalo现在还很小，我很忙。buffalo现在的核心功能只是一个web远程调用并且java/javascript双向透明序列化的library, 谈不上framework. buffalo还缺少大量的文档来帮助开发者迅速起步。将来要添加的page module, component module, validation module, 等等，还有很多工作要做。然而我还要为付给我薪水的雇主工作，并且加班，甚至某些周末；每天回到家里我也会累，也会不想动。谁知道在这样一种状况下，发布一个roadmap, 然后引来若干期待，会不会最后因为承诺没有兑现而死得毫无尊严呢？Roadmap其实发布过，不过都是在小范围内：buffalo的论坛(后来被迅速的删掉)，BJUG聚会的白板上，以及发给nemo的邮件。
不怕慢，只怕站，buffalo会一直走下去。
buffalo 1.2alpha1 released
buffalo 1.2alpha1 发布，包含如下特性：
* integrate prototype
* refactor and rewrite whole code into prototype-like.
* split javascript source into 4 parts: core, call, reply, bind
* modify build.xml, concat the 4 parts into one js in the dist target.
* modify the event system, change to buffalo.events["onLoading"]…
* some bugfix
* 全部演示页面翻译为英文（以后发布版本的主要语言），多谢清风
下载地址：
http://www.amowa.net/buffalo/download/buffalo-1.2alpha1.zip
此次的发布比原来声明的时间大约晚了三周，主要原因是一直找不到支持subversion的代码仓库。跟dev.java.net邮件往来多次，最后得知无法获得svn服务，只好作罢。多亏了曹晓钢的鼎力帮忙，在生病的情况下依然帮助我搭建并调试svn. 祝愿他早日康复。现在代码放在了redsaga上。
本想将版本号定义为1.1.1alpha, 但是由于本次版本变更在javascript部分实在巨大，完全集成了prototype的基础设施，写法跟过去有了很大不同，因此更改为1.2. 在外部api调用上，最大程度的保证了跟以前遗留代码的兼容。如果发现有问题，请在buffalo论坛中提出。很多常见的问题已经在那里提出了。
之所以集成prototype, 是因为他的提供的语法级别的基础设施相当便利，并且在常见的HTML操作的处理上，提供了相当多的方便的封装，如$, $F, Form等，我相信这些便利的方法会给web开发者带来更高的工作效率。
自这个版本后，buffalo javascript部分将不再作重大更新。剩下的工作将专注于java部分的工作，包括效率，bug, 以及最主要的部分：页面框架。
建议，意见，欢迎发往buffalo 论坛http://groups.google.com/group/amowa。最后向那些久等的朋友们说一声：对不起，来迟了！
One Page, One Application
前言：这篇文章本应该在一个月前就写出来，但是因为种种原因，腹稿打了数十遍，现在才有时间提笔来写。文中某些观点相对目前的web应用比较前卫，阅读者应当根据自己应用的具体情况，对此文进行批判的阅读。
一 定义
One Page, One Application(后面缩写为OPOA，或者1P1A)， 含义很简单：一个页面就是一个应用。在众多的基于Web的MIS系统中，没有人关心页面的组织形式；大多数稍微复杂的MIS系统，都采用分祯(Frame)的方式来组织页面，这样，在进行业务操作的时候，url的变化表现在一个框架页面内，从浏览器的地址看起来，只有一个地址；更有甚者，一些应用干脆弹出一个去掉了浏览器菜单、工具条、地址栏、状态栏的窗口（比如招商银行、民生银行的网上银行系统），连地址都看不见。因此，一个页面就是一个应用，从用户的角度来说，对于操作型系统，是一种非常自然的体现。用户无需了解每一个具体的操作对应的地址是什么。
这种设计背后的含义实际是：是希望由程序来控制用户的行为，还是反过来。在操作型系统中，每一步的操作往往被业务含义严格定义，无论是应用的设计者，还是其使用者，都希望在一种受控的状况下来进行操作。例如，一个审批动作，用户更希望是通过一个按钮来触发，而不是访问类似于/approve.action?itemid=123的方式。
二 场景
显然，OPOA的设计只能针对那些对URL不敏感的系统，或者说操作型系统。绝大多数MIS系统都属于这一范畴，Email系统也是这一范畴，其他领域，如监控系统，聊天室等都可以采用这种思路。反面的例子是，对于内容型系统，如新闻系统，Blog系统，论坛系统，用户更希望能够通过一个明确的URL来定位页面内容，搜索引擎也喜欢这种地址。这种应用需要的是一个合理，易懂，明确的地址。
三 设计与实现
大多数MIS系统，无论是有意识或者无意识，都遵循了OPOA的思路。要么采用框架，要么采用弹出窗口来屏蔽URL的直接访问。实现上也很简单，这里就不再赘述了。注意到上述的OPOA地实现只是对用户而言，看起来好像是一个页面一样，但实际上还是有众多的action， page在后面工作。
下面我要说的一种实现是，采用AMOWA/AJAX技术来实现真正意义上的OPOA. 简而言之：主页面（或者称布局页面）只加载一次，其他的操作页面通过AMOWA/AJAX技术来加载，并将其中的操作脚本与布局内容分开，最后进行展示。这个设计的原型在buffalo-1.1dr版本中。细心的开发者一定能注意到，在切换不同demo的时候，只是调用了一个switchPage函数，将不同的页面进行读取并显示。demo的演示速度相当快，因为每次只读取一小部分页面；如果加上缓存机制，将页面进行缓存，那么更快了。
首先存在一个布局页面，这个页面定义了一个应用大致的外观，（例如，大部分MIS系统按照上中下三栏，中间部分左右两栏分别为顶部logo, 操作菜单，具体操作内容，底部状态栏）。用你喜欢的网页编辑工具，将这个页面设计美观，然后按照应用的要求，将页面进行拆分。此时的拆分不用Frame了，只需要在不同的部位加上<div id=”…”>就可以。
然后在主页面定义一个函数，例如switchPage, 将这个函数使用在需要进行页面切换的地方。在buffalo的sample中，switchPage函数这样实现：
function switchPage(page) {
pageBuffalo.remoteCall(“pageService.loadPage”, [page], function(reply) {
var pageObj = reply.getResult();
Buffalo.getElementById(“body”).innerHTML = pageObj.html;
if (pageObj.script != null || pageObj.script != “”) {
execScript(pageObj.script);
}
});
}
你可以用任意你喜欢的AJAX/Amowa引擎来做这件事情。
剩下的工作都可以想象了。你可以将web应用的网页资源全部用html编写，并放在一个不为人知的地方，而通过pageService来读取他们；你可以任意组织你的应用外观，更加自如的切换他们。应用的URL地址永远只有真正的一个，你的应用也要比别人快很多，因为只加载那么一小块内容。
四 小结
AJAX/AMOWA的兴起为我们开阔了很多视野。比起原来的web框架，这种OPOA的方式能够更快，减少更多的编码量，并提供更好的用户体验。当然，上文中提出的只是一个原型实现，如果尝试自行实现，可能更多的东西需要考虑，如安全，缓存，事件回调机制，内存管理等等。但这将是一个方向，一个可以提高开发体验与用户体验的方向。
补充：
在buffalo的发展规划中，基于OPOA原则的页面框架将作为重要组成部分被加入。
Buffalo1.1 dr 发布
基本上实现了预期的构想，1.1中需要的功能都进行了扩充，包括Spring集成，绑定，自定义状态。
核心：
* Spring 支持，已完成
* 客户端兼容传统Burlap远程调用, 已完成
* 添加同步调用支持，已完成
* 可自定义异步调用时的动作，完成
绑定(in very alpha state, just show demo only)：
* 复选框，下拉列表框
* 表格
* 与JST集成
文档及演示：
* 改善的demo页面
* buffalo重写的j2ee blueprints ajax演示
欢迎各位使用！
下载：http://www.amowa.net/buffalo/download.html
http://www.amowa.net/buffalo/download/buffalo-1.1dr.zip
ps. 本版本是开发版本，文档很不充分，是为那些迫切等待1.1特别是Spring集成特性的项目准备的。在发行包中作了相关的例子，基本上都很简单，很容易上手。另外， http://groups-beta.google.com/group/amowa/ 是新开辟的专门讨论buffalo和amowa的论坛，有什么问题可以在这里提，也可以去那里。
用Buffalo完成了一个j2ee blueprints中ajax autocomplete样例
今天抽了点时间，完成了J2EE Blueprints Ajax样例中的AutoComplete. 以下是执行结果：
结果证明，用buffalo开发ajax应用，与j2ee blueprints自带的样例相比，能够大大提高开发速度，减少编码量;-)
下载: buffaloajax.zip 使用buffalo 1.0alpha.
请直接将zip解压缩到tomcat/webapps路径中，然后在浏览器中访问：
http://localhost:8080/buffalo-ajax/ajax-autocomplete.jsp
http://localhost:8080/buffalo-ajax/ajax-autocomplete-withbind.jsp
J2EE Blurprints Ajax: https://bpcatalog.dev.java.net/nonav/ajax/autocomplete/frames.html