flex漫谈

若干年前，我还在CitiBank工作的时候，全球包括国内IT界就有很多WEB开发者热论Rich Internet思想，众多IT媒体纷纷把RIA当作一个时髦的词汇挂在嘴边，时不时地品评一番。而各网络技术供应商也在暗地里思考着是不是新的机会到来了。当时正是全球java企业级技术开发高速发展的时期，OpenSource运动也在如火如荼的进行着。有一天，头召集我们说Macromedia（当时还没有被Adobe兼并）已经实现了一个实验版本的解决方案，名字叫Flex，让我们关注一下云云，因为下一个项目要用到它。于是从那时起便开始了 Flex之旅了。我想我们是Macromedia Flex最早的客户。Flex1.5精彩的UI组件给我留下了深深的印象. 一直到现在都密切的关注着它的发展，用它实现过很多让很多人激动人心的功能，同时也经历着由于Flex先天的不足所带来的困惑，以及每个困惑后面的解决方案。从第一个Beta版本的脆弱到现在2.0的进步，我能明显地感觉到它在成长和发展。我个人也在成长和发展。想以一个过来人的视角告诉国内这些被 Flex地魅力所打动地人们一些经验和教训。以及怎么发挥Flex最强悍的地方，巧妙地避开它相对不稳定和脆弱的地方。只要注意足够的细节，我的实践和经验告诉我，Flex总能让人激动人心！

现在，我想首先随便举例介绍一些Flex的短处。从最早的版本1.5开始。

1 不支持鼠标双击事件（解决方案是用两次时间间隔100毫秒的单击事件来模拟），2.0有所改观。

2 Flex的FlashSession和IE的标准HttpSession在Tomcat,WebLogic上部署时没有问题，但是在Unix的JRUN上时，Post请求参数不同步（解决方案是在Remote Object实现中手动同步必要的参数，比如如果你把Spring中的Facade Object作为Remote Object）2.0有同样的问题。在WebService作为Server端的通信方式时没有类似问题。

3  前期绑定和官方声称的不一致。组件绑定在Flex中分为前期绑定和后期绑定。当Client端装载编译过的mxml或as码流时首先出发的事件是 Initialize然后是CreationComplete，当我们分别写两个handler相应这两个事件，如果后期绑定可能用到前期绑定时装载的数据，你就会发现数据有可能会没有转载。原因有若干，在下一篇文章中详细介绍。

4 FlashPlayer 9以前的实现，类层次结构太深，实现很机械死板，存在很多重构的可能，比如一个应用中包括若干容器和组件，每个组件的初始化都要调flash类根结点相同的构造器。你配置好Flex自带的Profiler，就可以在Console中看到整个应用在底层的对象创建初始化的所有过程。只要在flex- config.xml中打开开关然后再做些额外的配置就可以了。（解决方案是写一个底层flash类Singleton的类工厂cache所有底层 flash类，此方案非常见效，flex并不是想象中的那么慢！）

5 本身没有好的pattern可以直接利用，容易造成mxml和as混在一起，可以选择cairngorm，这个不错。我将单独写一篇关于CAIRNGORM架构的文章。不过2.0时已经被集成进来。

6 CellRender存在数据类型DataType不匹配的Bug等等。

以上说了这些，有些朋友可能有些失望，其实大可不必。我们要保持一种客观的态度，等我把Flex的优点列出来以后，你又会充满信心了，其实，任何产品都有优势和劣势。另外，以上我所列的东西都是我在实际的开发中碰到的，到后来你会发现，等你做完项目必须的优化动作后，反而是数据传输所消耗的时间比 Flex组件初始化的时间要长一些，那时可以采用在Server端做个Cache以及Client端Lazy Load的策略。想一下Flex都可以做全球各大股票市场行情实时显示和分析，还有什么它不可以做的呢！
==============================================================================================================

支持的：
在Action Script的历代版本中, 没有任何一个UI是支持HTML所有的标签的, 它们只支持HTML一部分的标签.
TextArea这个UI也是一样的, 只支持HTML里少数标签, 比如加粗(<B>内容</B>), 或者斜体等等这些基本标签.
表格标签<table>是不被支持的, 要用表格的话, 我建议你用DataGrid组件, Flex 2里的DG比Flash 8的漂亮很多, bug很少.
不是。java is a programing language!
Flex技术是Micromedia推出的，此公司相续推出了两个版本Flex1.0和Flex1.5，但是由于他们所设计的IDE和生成的flash文件太过于臃肿，所以一直声誉不隆。
2005年，Micromedia被Adobe公司收购，Flex2.0和Flex3.0相继推出，Adobe改良了FlexBuilder和SDk，使得开发Flex变得简单，而且生成的.swf文件变的更小。于是这门技术才开始在国外盛行起来。
总的来说，flex是大势所趋，flex+java的J2EE开发在此后一段时间将是主角
oracle是主流数据库, ajax,既然有了flex,ajax可以不用学了
flex资料确实少,但flex3的中文书还是有几本的,况且现在flex4快要出了,赶紧学习吧。
另外，于Flex竞争的还有微软的SilverLight.最新消息，Sun公司也推出了javaFX,其实都是RIA。
不过由于Flex率先占领了市场，所以支援Flex的开源的东西也相对多很多，所以此后一段时间当主推Flex。

票数: 0

sdihei 2009-3-13 下午12:52:24 218.93.127.* 举报

取这个标题,难免会惹来幼稚和可笑之闲,打心底压根儿没有拿这两者来比过,因为这两者是否具有可比性本身是个疑问.可是最近一些朋友的公司却一直在UI的技术选型上犯愁.一些朋友这么问我,所以我想把自己的想法罗列在此,仅供参考.
先申明,我不是什么牛人,也不是FLEX和EXT方面的高手,甚至对EXT并没有在项目中亲自实践过,写此文之前我问自己,凭什么在此发言? 最后我找到一个说服自己的欠充分的理由.既然有人发问,就应该个答案,既然我不能更清楚地说出答案,何不以此做为源头,让更多的人来揭开这层面纱,此文难免落入俗套,请大家海涵.
不啰嗦了,进入主题吧.
FLEX和EXT该选谁?
一:从项目的风险上来考虑:
项目能否成功, 一定程度上并不关技术鸟事儿.因为不同的技术可能达到同样的效果.而我们往往只选取最有把握的一种技术,这就是让项目归避了风险,那么这两者中哪一种技术你更有把握呢? 大家自己更清楚,我可以大概地分析下两者目前使用现状来做个推测或猜测.不排除有例外.
FLEX在国内已明显比国外慢了半拍,从 FLEX的相关学习资料可以得出这一结论,记得从FLEX2开始我重新开始了对FLEX(以前玩过FLASH)的关注,那时我还在神龙汽车公司里做实施项目用的是SSH架构.项目中有很多有关经销商的数据需要统计和比较,客户非常希望能够直接在系统中看到各经销商特定数据项比较的结果,当时苦于没能说服经理采用FLEX的CHART来实现这一功能,而采用了BO报表这个庞大的系统来”高射炮打蚊子”,当时提出FLEX技术项目组的同志们闻所未闻,我简单地说是FLASH的一种技术,大家听罢都敬而远之.说FLASH依赖于FP.后来学习FLEX变成了我的业余爱好.当然现在在国内大概不会再出现类似的情况了,FLEX以及微软的SL大有山雨欲来风满楼的架势.CSDN的孟岩说”RIA是趋势”,我想倒底是不是趋势大家能感受得到.在这里我想表明一点,是 EXT已经被众多企业以及用户所接受,但FLEX还在考验和推广的路途之中.回到风险的考虑上来讲,你的团队中真正懂FLEX的人不多,或者根本就没有. 因为大家都没有FLEX方面的经验积累,你贸然采用FLEX,一旦在你的项目中遇到FLEX本身或者你的团队不能解决的难题,而又很难在寻求外界的技术支援时,你的项目势必为摇摇欲坠.这种惊心动魄我想大家都不想感受.而EXT听起来虽然是个新名词,但如XX人所说,AJAX只是一个新瓶装老酒的DD,我们几乎不需要额外的学习就可以完美的实现”拿来主义”,我们还可以根据自己的需求来修改内部的代码.所以就目前来讲,EXT的技术风险远低于FLEX.
二:学习和培训的成本:
要上一个项目,你的团队没有FLEX的经验也没有EXT的经验积累.别无它法,一:让团队成员自学交流,二:给团队成员培训一下.而不管是学习还是培训,EXT会更快地让大家所接受,所以EXT的学习培训成本或者说成是使用成本更低.(当然这只是就当前的项目而言,从公司长远的考虑,学习FLEX这个投入可能会得到更高的回报, 这是后话).
三:企业运营的成本:
BS结构的 DD,SERVER是运营时的重头戏,带宽的大小,服务器的负载能力….因素,在项目开发之前技术选型时都要经过深入考究,本着”问题都要在项目开始之先暴露的原则”,我们不能视FLEX项目的更高的带宽要求而不见;FLEX在第一次将整个项目SWF下载到客户端缓存,所以项目大载入会非常慢,鉴于国内的带宽状况似乎还很不乐观,这一点是几乎是FLEX技术选择时最为头疼的问题,这里或许有人会反驳说,有办法解决:我想很严肃地回驳,没办法解决,运用 RSL以及MODULE只能缓解这种尴尬;
针对这一尴尬.ADOBE官方有这么一说,FLEX是为企业级用户准备的,当然你做的是企业级方案,那这一尴尬确实可以不再让其蒙羞;所以FLEX在外网的解决方案的使用上似乎要更加慎重考虑
再回到话题上来,FLEX与EXT相比所需的带宽要求要高得多,最终用户的网络带宽不理想,你用FLEX做再华丽的,再炫,再牛的用户体验,他也体会不到. 当系统的并发数急剧增加时,企业的服务器要相应地提高对用户的响应速度,也需要加大带宽,运用木桶原理,可能需要增加的带宽不小(本人没有数据来说明,因为没有做过测试),支付的费用也会成若干倍增加.
四:开发效率和维护成本
看到上面,好像我更倾向于采用EXT,似乎我把FLEX说得一无是处,不然,FLEX也是时代的英雄,只是他的演出才刚拉开帷幕,从开发效率上来讲EXT根本没法跟FLEX相提并论,