我需要什么样的RIA Client Framework

研究flex有一段时间了,一直想写一点比较实在的东西。然而真到动手的时候往往又被困住了。

我现在真的懒了,过了原来学js时不用任何framework裸奔干活还不忘了写得很oo的年纪了(其实那时候我在做js方面的intern)。每次在脑子预构要做的时候,发现自己不得不做这么多“dirty work”,重新发明那么多轮子,一下就把我给吓住了(如果有钱发什么也吓不倒我)。

结果是,我什么大东西也没编,倒是一直幻想一个好用的RIA框架应该是什么样子(也就不限于flex了,如果gear、sliverlight、java fx方面上能用类似的东西我会考虑立马转向)。所以就随便写一点想法在这里,没准这种东西已经有了也可能的说,如果这样的话,麻烦在回复里推荐给我吧

—懒懒的分割线—-

这里先撇清我说的RIA是带着Server端的(不然怎么叫Internet App),所以题目中说的是Client Framework(不过很多东西还是要server配合才能搞)。Server端提供Service(RESTful、SOAP、AMF或者什么都行)。Server和Client之间传递xml、json或者什么编码的value object。

接着看客户端,MVC是必须的。不过这部分已经从Framework角度讲已经没问题了,无论是PureMVC还是Cairngorm都已经够用了。所以我就每一个部分的说

Model部分:

1. 统一的model class。指的是server端和client端model的统一,现在一般得搞两份,实在没必要。理想状况下用同一份model,server或者client专用的属性或者方法用继承或者annotation说明。

2. 考虑server端代码不可见的情况。至少可以通过server返回的vo生成model的桩(soap没有这方面的问题,但现在restful居多)。

3. 对本地数据库管理的封装。air和gear都支持sqlite,在本地缓存数据的好处是显而易见的。但是现在开发人员需要事无巨细地处理这个功能。理想情况下,首次创建数据库,client升级时数据库的升级,等等这些常用必要操作,框架应该封装好。开发人员提供必要的sql script即可。

4. ORMapping。这个不废话了。

5. 离线支持。Client数据同步到Server,参考greader离线阅读的方式。这个能力应该被框架支持,开发人员需要说明那些操作可以离线处理,如何在本地缓存操作结果,同步时机即可。

6. Server更新的处理。用于处理在本地缓存数据之后,server端数据更新的情况。需要server和client统一的方案。最理想情况下是应该有一种开放、通用的协议被广泛支持。大概思路是client提供时间戳和资源类型,server返回时间戳之后更新的资源。

Controller部分:

一句话就是更强的Comet。现在的观点Comet是server push data。考虑Rich Client,可以换一种观点,变成server调用client的功能,原来push的data只是参数(所以放到controller部分)。其中现在Comet谈到传输协议一层,但是之上还应该又一层互操作协议以及对应实现。这里:

1. 首先是让server和client很好地相互理解。至少也是一个类似xmlrpc的东西,从发起调用到调用成功,中间打包、拆包、client上的method dispatch之类全部透明。

2. 其次是对常用功能的封装。连接,断开等等。也要透明。

3. 最后考虑server和client不是同一方开发的情况。不同于client invoke server的调用,这里的反向调用是从层级结构上讲是下层调用上层。IoC原则,server方提出接口描述,client实现。接口描述语言肯定是互操作协议的一部分,但是扮演的角色和传统稍有不同。

View部分:

这里我能谈的不多了。只随便说一两句flex。

1. 需要一个更好的中文默认skin。现在的默认skin完全不适用于中文。

2. 更容易地借鉴(抄袭)设计。好吧,我到底不是一个设计人员。如果不是网上有那么多“免费”的css,我估计连勉强看得过去的html页面都写不出来。flex这方面门槛太高了。联合上面那点。业余开发人员很受打击。

—-又是分割线——

信手写了一大篇,半是存底备份,怀疑中间有一些点还是很有意思可以做一做玩一玩的。不过原来胖客户的时候以及现在在一些c/s体系结构的应用领域里(例如网游、数据库),估计类似的东西或多或少都解决了一些。

所以很多东西也许只要有对应的走http的轻量级版本就好了。

Burning Google Chrome

"We knew we had to break her, burn her straight down, or she might come after us." – William Gibson, "Burning Chrome"

珂萝米,不知道为什么是这个名字,不过这个名字在Cyber空间里是个坏角色。

如果这不是另一个不合时宜的愚人节新闻,那么大概在24小时之内我们就可以下载到这个Google的新浏览器,Google Chrome。

目前比较完整的消息都来自这个漫画(题外话,很难适应美漫,一点代入感都没有地难读)。要点是这样子的:

  • 稳定性,多进程架构(每个tab是一个进程,独立的js线程,同时内置一个任务管理器之类的东西,让用户监控或者中止不适当的tab页)
  • Webkit用于html渲染,加上全新的jsvm——V8(class支持类似虚表的机制,JIT,更好的GC)
  • 用户体验(地址栏搜索,布局类似Opera基于浏览历史的快速索引页,关闭后清空所有浏览历史记录的只读模式,Popup确认)
  • 安全性,Sandbox,浏览安全(基于Sandbox的malware防护,基于黑名单的Harmful Site防护)
  • 内置Gear,开源

仔细看一下,其实新东西不多,三个值得提一下的。

第一个是每tab每进程的架构。这方面其实不了解,所以不多说。总之漫画里google讲了一些多进程非常通用的好处。而具体效果,包括速度、内存的使用等等,还要用实物测试才知道。

第二个是v8,新的js引擎。基本上所有做前端的人的想法是一致的,标准的反派形象。因为不管新引擎有多好,很直观的一点是,调试兼容性的工作量的又增加了。对于开发人员来说,最邪恶的事莫过于此,因为这是让已经混乱的世界更加混乱。虽然在测试之前一切结论都是草率,不过肯定的是一旦v8的兼容性表现不好,而chrome又占据一定的市场份额的话,那么这对所有前端开发人员来说都是噩梦。(另外,值得注意的是fx3.1的js引擎也是新的——TraceMonkey

第三,在比较high level的层面值得注意的是Gear的集成。所以chrome的目的大概并不是浏览器市场。对于浏览器市场,和mozilla有良好关系的google大可不必扮演一个坏人来搅局。但是如果是作为RIA的最后一块的拼图,chrome是合适的。至此,google有了浏览器+插件+web应用的完整RIA方案,结果是google得到了将web应用的功能和体验再进一步发展的可能性。这一点是ms、adobe、mozilla、yahoo和apple都比不了的。长久以来Google Gear一直是一个低估的角色,也不普及。然而从上次google developer day上的演示来看,gear还是具备相当能力。相对与flex和sliverlight来说,gear具有的无可比拟的优势,因为gear可以从google自己的web应用那里获得进化的方向。相对与flex和sliverlight,gear避免了高大全而是切实地在实用性上下功夫——这恰恰也是google的特长。所以google是不是可以借chrome的东风,彻底改变RIA的局面,这个也算值得大家仔细观看的事情吧。

最后,不得不说,历史真的总是惊人的相似。又一个新浏览器~如果有一天,我们发现chrome之外的浏览器无法获得google系列应用的全部功能和最好的用户体验,我们会不会又一次扔掉手头习惯的浏览器而转向chrome呢?所以呢,开篇的那句话就让ie、fx、opera、safari、flex、sliverlight等等的大家们共勉吧~