让Ajax框架Buffalo支持JSON协议而非仅仅自定义的XML协议[JS前端及单元测试完成]

itstarting

浏览: 150322 次
性别:
来自: 杭州

最近访客更多访客>>

sp42

黑小子

winting

yeyeyeid

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

Java框架

单元测试 json XML 框架 Ajax

Buffalo默认实现了一套很棒的自定义XML协议（具体请参考拙作《Ajax框架Buffalo深度研究》）。

然而在崇尚“标准”的当下，很多人对这种“非标准”的自定义的协议并不感冒，哪怕它再好。

在这种情况下，本人也是本着对Buffalo的继续研究、提升自我的态度，尝试基于org.json的“正宗”JSON参考实现RI，让Buffalo完全支持JSON标准协议。

本来打算自己默默研究，等完全成型之后再发布出来，然而自《Ajax框架Buffalo深度研究》发布后，在社区所凝聚的人气之旺，让我有些震惊（或者说惊喜），继而灵机一动：何不利用社区的强大平台，在线开展此项工作呢？

不能保证每天甚至每周都有让人惊喜的进展，仅希望通过这种方式，鞭策自己的同时，也获得更多社区高手的批评斧正，快速提升，少走弯路。

接下来的工作，欢迎各位踊跃拍砖，谢谢！

2010-02-08，状态简述：

1）前端js已经编写完成：充分结合XML协议和JSON协议，完成了代码的重构

2）单元测试已经完成，并提供了完整的参考XML协议的js单一测试用例（同样基于script.aculo.us 的unittest.js）

3）升级prototype.js到最新的1.6.1（其实buffalo对prototype.js依赖不大）

接下来的工作：

1、完成前后端集成测试，并完善demo

2、适时开展RC

2010-01-25，状态简述：

1）后端代码重构完成，并已纳入buffalo SVN, 建立了新的branch，位于branches/json/；

2）接下来工作的重点是：a.着手编写前台js; c.并结合demo完成集成测试。

分享到：

Maven+Jetty免静态文件死锁的处理 | Ajax框架Buffalo深度研究

2010-01-14 16:01
浏览 2922
评论(27)
论坛回复 / 浏览 (27 / 7972)
分类:Web前端
查看更多

7 楼 itstarting 2010-01-15

改造：BuffaloInvoker.java
 

根据BuffaloProtocal.java的改造而做出的适应性改造。
首先增加了一个类的私有变量protocol，用以表达所用协议：


<pre name="code" class="java">private String protocol = "XML";</pre>

 
废弃原有获取单例的方式并增加新的需要明确协议的方式：

<pre name="code" class="java"> /**
* get the instance for default xml protocol
* @return
* @deprecated use getInstance(String protocol) instead
*/
public static BuffaloInvoker getInstance() {
return getInstance("XML");
}

/**
* get the right instance for the protocol
* @param protocol
* @return
*/
public static BuffaloInvoker getInstance(String p) {
if (instance == null) {
instance = new BuffaloInvoker();
}
instance.protocol = p;
return instance;
}
</pre>

 
三处BuffaloProtocal.getInstance()的地方，改为：BuffaloProtocal.getInstance(protocol)。

6 楼 itstarting 2010-01-15

改造：BuffaloProtocal.java
 
经进一步分析发现，BuffaloWorker调用了BuffaloInvoker实例的invoke方法实现输入流的解析（unmarshal）和输出结果对象的序列化（marshal），而BuffaloInvoker所使用的是<a name="OLE_LINK1">BuffaloProtocal</a>的实例。
再看看BuffaloProtocal实例的代码就知道，这里存在大量耦合XML协议的部分。
解耦在所难免。
此类改造由此产生了两个目标：
1、 应该要能区别所用的协议；
2、 实例将根据不同的协议初始化对应的StreamReader和StreamWriter。
为此，首先增加了一个类的私有变量protocol，用以表达所用协议（这个变量后续需要重构，谁知道后续还会冒出什么协议呢，对吧）：
 
 
 
<pre>private String protocol = "XML";</pre>
 
废弃原有获取单例的方式并增加新的需要明确协议的方式：

<pre name="code" class="java"> /**
* get the instance for default xml protocol
* @return
* @deprecated use getInstance(String protocol) instead
*/
public static BuffaloProtocal getInstance() {
return getInstance("XML");
}
/**
* get the right instance for the protocol
* @param protocol
* @return
*/
public static BuffaloProtocal getInstance(String p){
if (instance == null) {
instance = new BuffaloProtocal();
}
instance.protocol = p;
return instance;
}
</pre>

 

 

 
 
注意：我感觉上面这样写会有线程安全问题，不知道各位怎么看？
 
改变原有的marshal和unmarshal方法中直接绑定XML SteamReader及SteamWriter的做法，通过if…else来判断（先这样，看以后再重构）：

<pre name="code" class="java">public void marshall(Object value, Writer writer) {
StreamWriter steamWriter;
if(protocol.equalsIgnoreCase("JSON")){
steamWriter = new JsonStreamWriter(writer);
}else{
steamWriter = new FastStreamWriter(writer);
}
marshallingStrategy.marshal(value, converterLookup, steamWriter);
}

public BuffaloCall unmarshall(Reader reader) {
StreamReader steamReader;
if(protocol.equalsIgnoreCase("JSON")){
steamReader = new JsonStreamReader(reader);
}else{
steamReader = new FastStreamReader(reader);
}
return marshallingStrategy.unmarshal(steamReader, converterLookup);
}

public BuffaloCall unmarshall(InputStream inputStream) {
StreamReader steamReader;
if(protocol.equalsIgnoreCase("JSON")){
steamReader = new JsonInputStreamReader(inputStream);
}else{
steamReader = new FastInputStreamReader(inputStream);
}
return marshallingStrategy.unmarshal(steamReader, converterLookup);
}
</pre>
 


 

 

注意了，这里我先定义了三个类，分别为：
JsonStreamReader——实现io/SteamReader接口，用以解析JSON输入流；
JsonInputStreamReader——这个得再确认，原先XML协议下的说法是Opera下有编码问题才做的，先照葫芦画瓢改造；
JsonStreamWriter——实现io/SteamWriter接口，用以序列化执行结果并输出JSON流
上述三个类将是本次扩展实现以支持JSON协议的重中之重。

5 楼 itstarting 2010-01-15

经昨天晚上的分析，上述改动不应在ApplicationServlet做，而应该在AbstractRequestWorker.java。即上述在ApplicationServlet的修订无效。
 

 此时要改造的是AbstractRequestWorker.java，即把原先打算在ApplicationServlet的改动，调整在此类做：



 定义一个类全局的变量：




<table class="MsoTableGrid" style="border-collapse: collapse;" border="1" cellspacing="0" cellpadding="0"><tbody><tr style="">
<td style="padding-right: 5.4pt; padding-left: 5.4pt; padding-bottom: 0cm; width: 426.1pt; padding-top: 0cm; background-color: transparent;" width="568" valign="top">
private static final String PROTOCOL_ATTR = "X-Buffalo-Protocol";
</td>
</tr></tbody></table>
新增getProtocol的方法：


<table class="MsoTableGrid" style="border-collapse: collapse;" border="1" cellspacing="0" cellpadding="0"><tbody><tr style="">
<td style="padding-right: 5.4pt; padding-left: 5.4pt; padding-bottom: 0cm; width: 426.1pt; padding-top: 0cm; background-color: transparent;" width="568" valign="top">
/**
 * Get the protocol
 * @return
 */
protected String getProtocol(){
 //get the buffalo protocol from request header ‘X-Buffalo-Protocol’
 return (String) RequestContext.getContext().getHttpRequest().getHeader(PROTOCOL_ATTR);
}
</td>
</tr></tbody></table>

在这个抽象类做有什么好处呢？能确保所有Worker都能共享此变量。

 
拿到以后怎么用呢？目前并没有现成的办法。
后面应该需要较大的改造力度了。

4 楼 itstarting 2010-01-14

我很好奇的看到有8名高手投了隐藏贴，如果大家已经有好的实现，不妨发给我学习参考，谢谢！

3 楼 itstarting 2010-01-14

当然了，Buffalo.Call还需要增加json方法，类似于xml，用以产生json的请求。
为了方便，这里先写死了，先把simpleService.divide走通再说：
<pre name="code" class="js"> // parse the call to json format
// TODO: now just for test
json: function(){
this._objects = [];
var jsonstr = "{'buffalo-call':[{'method':divide},{'double':1},{'double':2}]}";
return jsonstr;
},
</pre>
 
 
这回轮到修订后端的入口Servlet，即ApplicationServlet.java。
定义一个类全局的变量：
<pre name="code" class="java">private static final String PROTOCOL_ATTR = "X-Buffalo-Protocol";</pre>
 
在doRequest中获得协议名称：

<pre name="code" class="java">//get the buffalo protocol
String buffaloProtocol = (String) request.getHeader(PROTOCOL_ATTR);
LOG.debug("using protocol: " + buffaloProtocol);
</pre>

2 楼 itstarting 2010-01-14

首当其冲的是，得搞定入口问题。如何确保双协议的同时支持是关键？


 
首先定义一个全局变量：
<pre name="code" class="js">Buffalo.DefaultProtocol="JSON";//XML or JSON</pre>
 
 
协议的选择应该考虑基于每次的remoteCall，而不是全部要么这样要么那样。
此时需要扩展Buffalo.Call，新增参数protocol，并新增两个方法：

<pre name="code" class="js">initialize: function(methodname){
……
this.protocol = Buffalo.DefaultProtocol;
},

setProtocol : function(protocol) {
if (protocol!=null && (protocol=='XML' || protocol=='JSON')) {
this.protocol = protocol;
}
},

getProtocol : function() {
return this.protocol;
},
</pre>
 


 

 

然后在正式发出后台请求的地方（Buffalo._remoteCall），通过RequestHeader传递这个协议指令：

<pre name="code" class="js">try {
this.transport.open("POST", url, this.async);
this.transport.setRequestHeader("X-Buffalo-Version", Buffalo.VERSION);
this.transport.setRequestHeader("X-Buffalo-Protocol", buffaloCall.getProtocol());
this.transport.setRequestHeader("Content-Type", "text/xml;charset=utf-8");
this.transport.send(sendingXML);//this.transport.send(buffaloCall.xml());
} catch (e) {
this.events.onError(this.transport);
this.events["onLoading"](false);
return;
}
</pre>
 


 


这样，这个指令就可以从后端的入口Servlet（ApplicationServlet）获得。

1 楼 itstarting 2010-01-14

Buffalo原有的架构，就这个扩展的角度而言，基本还是合理到位的，核心部分均通过简约的接口定义，与具体实现进行了分离，内部也合理的运用了较好的设计模式实践。所有这些，均为实现JSON协议的扩展和改造打下良好的基础。
考虑到原有XML协议已经非常成熟稳定，整体实现基于JSON协议的扩展思路是这样的：
1、 改造原有与XML协议耦合过高的代码；
2、 实现基于JSON的io读写接口；
3、重新编写/扩展客户端序列化、反序列化机制。

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论