AJBridge重生

2010-9-2 20:44:07 开源抢沙发(1)

经过1个多月的努力，AJBridge终于重生了，说起这个还得感谢玉伯同学的 KISSY 和他诚挚的帮助。

说实话，“不当爹的不知道当爹的苦”这句话我可是深度体会了。

文档：

AJBridge：http://kissyteam.github.com/kissy-ajbridge/

KISSY.Flash： http://kissyteam.github.com/kissy/docs/index.html

历史：

2010年09月02日 AJBridge发布。 ver. release 1.0

同时完成 AJBridge 和 Store 的 API文档 http://kissyteam.github.com/kissy-ajbridge/

2010年09月01日 AJBridge 预发布。ver: 1.0.12 。

同时发布 flash 本地存储库 Store。

2010年08月26日 AJBridge review。并依据最新的 KISSY库特性进行了重构。

同日，Kissy-AJBridge库开始正式运作。

至此 AJBridge 正式成为 KISSY的继 KISSY editor 子项目的另一项子品牌。

2010年08月25日经陆陆续续的空余时间，终于将新人指引文档完成。

2010年08月16日开始撰写KISSY.Flash指引文档

2010年08月03日 KISSY 1.1版发布（已包含 KISSY.Flash）。

同日，基于该版本的 KISSY.Flash 和 AJBridge 以及 SWFStore 重新撰写并加入标准测试页。

2010年08月02日撰写完成 KISSY.Flash API文档。

2010年07月27日完成可运行的KISSY.AJBridge

2010年07月26日开始着手写KISSY.AJBridge

2010年07月25日 KISSY迁移至github安家。同时，确定了 AJBridge在 KISSY中所扮演的角色，见玉伯的《KISSY 迁移到 github.com》

2010年07月23日完成可运行的KISSY.Flash

2010年07月21日开始着手写KISSY.Flash

2010年06月30日尝试应用AJBridge的新白名单机制至SWFStore中。

由于YUI的SWFStore还在beta阶段，并且有一些bug。

考虑到后期维护以及和之前版本统一及合并的问题最终决定和KISSY的初衷一样，自己来创建。

2010年06月29日增加了AJBridge的AS部分的白名单机制，借鉴了 YUI SWFStore的白名单机制。

2010年03月18日某些原因接触了公司某WEB IM 的 flash相关部分业务。接触了YUI 的SWFStore.

意外的发现代码部分如此相似，似乎印证了本人“一个弹坑可以落数个炮弹”的结论。

同月参加“CM”项目，虽然竞标项目失败，但是从此接触了“KISSY”。

2010年01月04日应用到公司的一个内部项目，代号“HYQ”

期间发现并修复了一些代码

。。。孤独......莫非快死掉了么.........

2009年11月19日增加了demo，并修改代码，支持多事件多swf。

2009年11月11日修复一些bug，优化了代码 ver.r3。

2009年11月10日修复一些bug。ver.r2。

2009年11月06日第一版完整代码的 AJBridge 诞生,并上传至 google code 的 AJBridge项目。

同时又撰写了一篇博文做记录

2009年11月05日决定使用 google code 进行代码管理。

2009年10月28日决定开始编写 AJBridge。目的仅仅是封装AS和JS通信的公用部分，减少工作量。

KISSY.Flash新手上路文档完成

2010-8-26 13:21:31 开源抢沙发(0)

请访问 http://kissyteam.github.com/kissy/docs/flash/practice/index.html

KISSY.Flash开发札记---进化

2010-8-5 16:26:51 开源抢沙发(0)

说之前先说下KISSY.Flash的任务目标：

支持多SWF管理。
支持动态、静态两种方式获取SWF。
对第三方参数 flashvars的值进行有向过滤（动态）。
支持第三方参数flashvars的内容，深度大于1。
支持第三方参数flashvars深度大于1的内容JSON串化。
支持在线安装最新的flash播放器。
对不支持开发者期望版本的客户端提供具体的错误参考。

再说说这个库的构成。

flash.js 对KISSY抽象资源做了约定，便于未来的更改升级，并确立了 KISSY.Flash的命名空间。
flash-embed.js 当前 KISSY.Flash 具体逻辑和功能的实现主体。
flash-ua.js 针对KISSY.UA的扩展，提供对客户flash播放器版本判断以及开发者期望运行版本检测。

此次主要说的是第一条关于SWF多条管理的抽象资源 flash.js。

看第一次代码：

KISSY.add('flash', function(S){

S.Flash = {

instances: { }, //存储每个已获取到的 swf 的 html元素

archives: [] //存储每个swf的id

};

});

当初这样的设计是为了能对 swf进行通过序列操作，并能获得附加SWF个数统计，以及快速的对象获取。

而且当初设定了 KISSY.Flash 就是个静态对象，因此对 swf个数的获取需要动态的。

而之后的从简单和容易记的角度上来考虑，于是觉得用 swfs 代替 instances和 names 代替 archives 更好的从字面理解存在的意义和便于记忆。

KISSY.add('flash', function(S){

S.Flash = {

swfs: { },

names:

};

});

后来，玉伯同学说既然获取/操作swf都需要id，且并以此作为swfs的key，不如就直接将names称为ids。

看上去是个好主意，于是又有了

KISSY.add('flash', function(S){

S.Flash = {

swfs: { },

ids:[]

};

});

心想，这应该完美了吧，但事实上世界本就无完美，如人无完人一样。

在实际操作过程中真正通过 index搜寻 swf的用途很少，而开发人员往往在一开始就可以预定id。

KISSY的原则就是2/8原则，只挑最好的，不挑最少的。

因此再三考虑决定废弃 ids这个数组对象。

但是问题来了，没有了数组，我们就无法动态获取SWF个数，而具体的实现要在后续的 flash-embed.js中实现。

于是根据抽象资源提供基本接口的约定，因此决定向swfs中加入length属性，通过后续的增删操作提供增减操作。

而当时想到的是 swfs既然是个类 list 应该具备 length 属性，于是又有了以下代码：

KISSY.add('flash', function(S){

S.Flash = {

swfs: {length: 0 }

};

但是，总觉得这样写风险还是很大，比如某个 swf的 id 就叫 length。于是在存储规则中增加了一条规则：每个id都具有 “#”前缀。

这样就不会有污染，而且ID前带 “#”符合了 KISSY的DOM 选择器规则。这看起来很完美了。

可实际在做KISSY.Flash扩展的时候，问题又来了，由于swfHTML元素的id决定了as调用swf 唯一性，而这样的更改必然会对后续的操作带来一些工作。

比如正则处理ID。

但这样做又违背了 KISSY中的一个S ------简单。

于是基于以下两点考虑最终让此静态抽象资源对象走向了最“幸福”的一站：

swfs应该是个池，而且是应是个纯粹的“一一对应池”。
既然Flash就是个静态抽象资源对象，且管理多个实例，其本身也类似 collection ，更何况后续会有 add/remove/get，因此应该用最方便最易解的length。

于是。。。。事情就是那么简单。。。。。简单就是美嘛。。。。

KISSY.add('flash', function(S){

S.Flash = {

swfs: { },

length: 0

};

这样的好处可以直接通过 S.Flash.length获取到 Flash的个数。而之前则为了达成获取 Flash中 SWF的个数采用了 length()或len()去获取S.Flash.swfs.length。

总结：

事实上，我们在做开发的时候应该遵从第一直觉，既为了达成某项目标，其惯例或者说约定成俗的方式是什么。而理性往往不一定是对的，就好像对swf的个数统计就应该源于 swfs。但事实上作为使用者来说，更倾向于“我给谁了就向谁拿”的习惯，因此基于这2点将 length作为属性直接写在静态抽象资源类上更适合不过了。

下一篇我将会隆重的介绍 KISSY.Flash 具体使用方式和过程。

KISSY Flash源码：http://github.com/kissyteam/kissy/tree/master/src/flash/

KISSY Flash文档： http://kissyteam.github.com/kissy/docs/flash/index.html