QuirksBlog:
The AJAX response: XML, HTML, or JSON?
早先q篇文章在TSS上脓出的时候,我很快的览Q便一眼看文章作者所处的角度。事实上QAJAX概念的不完整和不严密性——异步的JavaScript + XML——导致作者将AJAX的输出分ZU类型:XML, HTML片断和JSON对象字符丌Ӏ?br>
首先看XML。对于RPC的数据传输,XML从来都是当仁不二的选择。对于将对象序列化ؓXML字符串的方式Q往往有两U选择Q一U是对象本w的属性作点进行输出,一U是利用语言的元数据Ҏ进行序列化输出。两者存在较大不同。对于第一U,输出案例如下Q?br>
<books>
<book>
<title>JavaScript, the Definitive Guide</title>
<publisher>O'Reilly</publisher>
<author>David Flanagan</author>
<cover src="/images/cover_defguide.jpg" />
<blurb>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</blurb>
</book>
<book>
<title>DOM Scripting</title>
<publisher>Friends of Ed</publisher>
<author>Jeremy Keith</author>
<cover src="/images/cover_domscripting.jpg" />
<blurb>Praesent et diam a ligula facilisis venenatis.</blurb>
</book>
</books>
而对于第二种Q输出案例如下:
<list>
<type>java.util.List</type>
<map>
<type>yourapp.domain.Book</type>
<string>title</string>
<string>JavaScript, the Definitive Guide</string>
<string>publisher</string>
<string>O'Reilly</string>
<string>author</string>
<string>David Flanagan</string>
<string>cover</string>
<string>/images/cover_defguide.jpg</string>
<string>blurb</string>
<string>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</string>
</map>
<map>
<type>yourapp.domain.Book</type>
<string>title</string>
<string>DOM Scripting</string>
<string>publisher</string>
<string>Friends of Ed</string>
<string>author</string>
<string>Jeremy Keith</string>
<string>cover</string>
<string>/images/cover_domscripting.jpg</string>
<string>blurb</string>
<string>Praesent et diam a ligula facilisis venenatis.</string>
</map>
</list>
前一U一般来说是同一q程内(同一JVM内)对对象进行序列化和反序列化的ҎQ在XML-Javal定一cȝ框架中比较多见,例如XStream,
JiBX, Castor{等。当同一q程内能够找到对象具备的正确cdӞq种序列?反序列化设计和实现都不太困难Q而且针对I值处理也比较Ҏ?br>
可以看出Q由于这U方式成本较低,有大量成熟的开源库可用Q加上在AJAX中的X(ML)的“理论”指gQ许多开发者采用这U方式将对象输出l前台浏?
器,然后利用览器的XML能力q行输出昄。从那篇文章中可以看出,q种工作是纯_的dirty work,
q且׃领域模型或者DTO的不同,输出的xmll构含义也不同,在对I值的处理上更是麻烦,在处理显C逻辑的时候,基本上很隑֜客户端对以这U方式传?
的XML以一U统一的方式进行还原。以q种方式来进行AJAX开发,规模应用还不能昑և弊端Q但是大规模应用出现Q领域对象较多时Q必然出现怨言。而我
们用AJAX的真实意囑ƈ非来无趣地去解析各种各样的XMLQ而是需要XML中代表的数据。至于XML是什么样子,除了调试阶段Q没有h会关心?br>
W二UXML的序列化方式是绝大多数跨q程q程调用协议/框架所采取的方式。SOAP/WebService如此QXMLRPC如此QBuffalo采用
的Burlap也如此。这U远E调用的特征是,在协议约定的条g下,调用方和被调用方需要保证数据语义的完整性。拿什么保证?是数据定义信息了。这些协
议的共同特征是采用谋一些标记来描述数据cdQint, long, float, string,
list...q样定义完成后,只要Ҏ协议QQ何语a都能以一U通用的方式对数据q行q原。AJAX引擎的概念也渐渐呈现——通过某一U协议,他就?
于中间的位置Q负责将调用方的h包装为协议,转化为执行方能够理解的动作加以执行;然后执行结果{化ؓ协议的|传递给客户端,客户端引擎将协议内容
解析够理解的对象l构传递给客户端,然后可以利用这个数据来昄了。XML-RPC如此QWebService如此QDWR如此QJSON如此Q?
Buffalo也如此?br>
lg所qͼUa使用领域模型特定的输出XML传递给客户端是一U相当原始的做法。他只在很低的层ơ上印证了所谓AJAX的概c然而,q种概念的深入思维l果便是一个AJAX引擎?br>
文中提到的第二种输出方式QHTML——应该被看作WEB的一个特例,应该说这是历史因素、浏览器能力、设计者等多方因素辑ֈ的一个^衡。许多历史应?
中,大多采用页面进行一定规则的分割Q然后include或者jsp 2.0
tagfile的方式对公共区域q行处理Q留下一部分进行动态显C。这里D一个例子:查询Q显CZc列表。传l做法就是上面一个搜索条件输入文本框Q下
面是搜烦l果列表Q处于同一个页面。原来的搜烦方式每次提交都要h整个面Q用户体验不太好Q现在需要改q。按照激q的Ajax做法应该是当搜烦按钮?
LQ调用bookSearchService.search(String
terms)的方法,取得l果列表Q然后Ajax引擎处理l果数据Q将数据反序列化为javascript对象Q开发者利用这些对象,要么利用DOM,
要么利用JavaScript Template, 在页面对搜烦l果q行展示。然而,问题出现了:
搜烦l果太多了,用DOM操作速度太慢Q?br>
开发者h手不够,没有旉Q而这个页面以前写q;
那么出现q种情况Ӟ很可能的做法便是Q见原来那个搜烦l果面刨去其他不相q的部分Q留下搜索结果部分,然后利用一个resultDiv.innerHTML=xmlhttp.responseText完事。这样做Q既辑ֈ了改善体验的效果Q也提高了开发速度?br>
输出HTML另外一U方式文中也没有提及。事实上QHTML不仅仅作为片断,更重要的是作为页面视囄一部分。在buffalo的demo中,可以看到所
有的面都被理h了,buffalo接管了视囄切换Q这U设计也存在于gmail/163新版邮箱中。这个应用比上面的HTML片断的用方式还?
重要Q因里是~存可以介入的地斏V通过不同的缓存策略,可以用L实际和心理等待时间大大减,从而进一步改善用h作体验,提升产品竞争力?
QPS. 在Buffalo 1.3中将加入客户端缓存模块,无需你动手,buffaloZ~存视图Q?br>
文中提及的第三种方式QJSONQ根据第一部分的描qͼ应该比较清楚了。实际上他扮演了一个Ajax引擎的角艌Ӏ这里不得不提的是,使用JSON的相当危
险的。因Z的协议表C语言本nl定太死。如果某一天,JSON协议变化了,那么使用JSON的应用基本上不可能应对这个变化——因回结果是
eval()得到的。而Buffalo协议隐藏v来了Q?.2版本甚至q服务器端的ServiceInvoker都将burlap实现依赖隔离开。现?
使用burlapQ也许某一天不用了Qbuffalo的应用照样可以运行。因为里面的l节都是透明的,作ؓ开发者,你只需要关注数据对象本w,而非用来?
q对象的那一堆字W?img src ="http://www.aygfsteel.com/mechiland/aggbug/25984.html" width = "1" height = "1" />
]]>