关于FLex 3 on Rails 框架感受

折腾了两天了 flex 和 rails。
虽然弄出了一个还算不错的demo application。
但是还是感觉怪怪的：

1. 对于Flex带来的好处有些疑问：
   传统的rails模式是erb + javascript + css.
   在跨浏览器的问题上要下点功夫，页面的美观和动感需要用css和javascript来解决。
   而在flex中，浏览器的问题被flash彻底解决。也不要一堆乱七八糟的javascript library了。
   jquery,ext 什么什么的都省了。唯一要用的就是actionscript。
  
   我感觉这样有好处也有坏处。解决跨浏览器的问题绝对是贡献。可是写actionscript + mxml就不大好说了。
   第一个就是效率。我不知道其他大大们怎么样。至少我感觉会actionscript的人比较少。精通的可能就更少了。
   传统的css + javascript对我来讲更加通俗易懂。
   不知道有没有人对比过flex的开发效率。是不是有明显的优势？
  
2. flex 生成的文件大小。
    一个很小的demo,只有list record,add record 和简单的 form validation. 一个pie chart.
   就生成了820k 文件。如果继续下去的话，岂不是要几兆的文件了？ 

3. flex 的运行速度。
    在我的笔记本上，运行demo的速度还是可以接受的。
    可是不知道像是这种rich client application运行在thin client 或者 critx上会怎么样。
    不知道有没有人试着在低端平台运行过用flex 做的application.

4. flex SDK 中的不足
    之前好像有人在帖子里说明了一下flex现在的不足。
    好像对于一些基本的mouse event支持的还不够。
    不知道有没有人能具体讲讲。

5. flex 和 rails 有点像 混血儿。
   已经习惯了ruby 和 rails 的风格，在把自己的 model 和 conntroller 都写好了之后。再来写写actionscript 真的是很不舒服。很像一个篇文章，开篇用日文，中段用中文最后用英文总结。感觉十分十分的别扭。
不过，也许有java 和 c++ 背景的人能适应的快点吧。

最后在讲讲flex对我来讲的最大好处吧。
第一个就是跨浏览器。第二个就是它可以和各种语言很好的结合。只要通过web services传递xml,json甚至是text就可以很好的和后台程序进行交流信息。对于有多种语言环境的开发者是个救星了。

最后献上一个小小的教程：flex 3 on rails 2

没有体验过flex 和 rails 结合的人士，赶快试试看吧。

评论

19 楼 Auckland 2009-12-02  

ltian 写道

Auckland 写道

todn211 写道

我刚用FLEX+JAVA完成一个流程设计器，楼主提到的前四个问题根本就不是什么问题。都有相应的解决办法。至于第5个问题更加不是问题，两种语言的切换来写又怎么了，你用ruby和JS不一样要两种语言间切换吗？以上的问题都解决不了，证明你是不了解ACTIONSCRIPT.

兄弟言重了。我所说的基本上是我这几天的感受。现在我正在继续研究action script。。。。。

看得出来，，楼主正在研究ing，那些问题会随着您对FLex的不断深入会得以很好地解决的。而且我认为您解决那些问题不会花太多时间的，因为你具备了很强的研究能力。

这话听的我晕晕的。

我也是个打工的。老板对flex感兴趣。我们就只能偷偷研究研究了。最有研究能力的人都去当老板了，然后指挥我们这些稍微有点研究能力的人去按照他的旨意继续研究。

研究对了，客户满意了，产品卖出去，公司赚钱了，我们才有加薪的可能。

所以只能继续研究。。。。。。haha

18 楼 凯旋人生 2009-12-01  

的确，楼主提的问题都不是问题哈。
前不久我山寨了个Flex的GEF的MVC框架，解决Flex图形化开发中的模型视图控制的耦合问题。
虽然还有问题，大体感觉还不错，只可惜我还没做完就被调到别的项目了。

目前基本上停了，郁闷中...

17 楼 ltian 2009-12-01  

Auckland 写道

todn211 写道

我刚用FLEX+JAVA完成一个流程设计器，楼主提到的前四个问题根本就不是什么问题。都有相应的解决办法。至于第5个问题更加不是问题，两种语言的切换来写又怎么了，你用ruby和JS不一样要两种语言间切换吗？以上的问题都解决不了，证明你是不了解ACTIONSCRIPT.

兄弟言重了。我所说的基本上是我这几天的感受。现在我正在继续研究action script。。。。。

看得出来，，楼主正在研究ing，那些问题会随着您对FLex的不断深入会得以很好地解决的。而且我认为您解决那些问题不会花太多时间的，因为你具备了很强的研究能力。

16 楼 ltian 2009-12-01  

现在，企业应用开发域的公司（SAP，ORACLE）都在大炒 “可视化”的概念，他们拿出的所谓“可视化”产品其实就是用FLex开发的漂亮界面。

15 楼 凯旋人生 2009-12-01  

chinakite 写道

针对楼主提出的这几个问题，我的看法是：
5. 与其他应用的集成
   基于HTML的系统集成其他的基于HTML的系统很容易，最惨的情况下也不过是使用iFrame来嵌入一下（SSO之类的我们这里不谈，与Flex无关），但是Flex的应用就不一样了，如果你需要集成其他的报表系统，集成其他的OA系统那就都是问题了，因为Flex与HTML页面的集成问题非常大。
   Flex应用集成其他的HTML系统更多是使用flex-iFrame方式，而这个iFrame与HTML的还是有区别的，因为使用的iFrame其实就是HTML的iFrame。这会带来什么问题呢？Flex应用还是需要在浏览器中运行的，它其实就是个swf，是嵌入在一个网页中的，在这个网页的document中它就是个Object，而嵌入的另一个iFrame是与swf平级的元素，嵌入的方式其实是在HTML中开了一个div，在这个div中嵌入一个IFrame，动态计算这个IFrame的宽和高进行模拟，而如果你需要在HTML上再弹出一些Flex的东西的话就会出现恼人的层覆盖的问题了，两个平级的层是不能嵌套的。我们目前的解决办法只能是尽量避免这种形式的交互，比如在嵌入一个HTML的地图时不要设计在地图上还要弹出Flex对话框的应用，同时如果HTML页面比较大的情况下，Flex的Menu也要注意躲开HTML区域，同时还要在界面切换的时候将iframe的div设成隐藏。
   嗯，总结一下就是——很麻烦！

关于这个问题，能否用图片表述下，
    —————————————————————————————————————————
    |HTML
    |     ——————————————————————————————————
    |    |swf ______________________________
    |    |    |div
    |    |    |  ____________________________
    |    |    |  |iframe
    |    |    |  |   ___________________________
    |    |    |  |   |flah menu??
    |    |    |  |   |
    |    |    |  |   |

14 楼 chinakite 2009-11-30  

Auckland 写道

chinakite 写道

---------------------------- 我是chinakite的分隔线 ------------------------------

上面是楼主提出的问题，其实在使用过程中发现Flex带来一些其他方面的问题倒是挺另人困扰的
1. C/S结构
   C/S结构带来的第一个问题是B/S程序员思想的转变，你不能要求所有的程序员都有过C/S开发的经验。用惯了Request、Response的B/S程序员还是更习惯一个request对应一个response，使用Get或是POST方式提交request，而Flex本质上是一个C/S应用的Client端，在Client端可以保持State，这会带来很多架构和开发上的不同，例如缓存、客户端State的使用等。如果不能很好地理解做Flex应用会很别扭。

2. 全异步事件模型
   这也是思想上的事，习惯了Java的程序员更熟悉同步模型，更习惯一种命令顺序执行的开发方式，而Flex是一个全异步的事件模型，哪怕你只是弹出一个Alert也要在Alert的回调中来实现该有的逻辑。实现上是没问题，但是带来的问题一是经验较少的开发人员容易出错，另一个是本来逻辑中很顺的代码会被回调拆分的七零八落，比如一个界面需要顺序调用几个远程对象，那么你只能在A的result事件中去调用B，然后再B的result事件中去调用C……
   当然使用Ajax也是同样的情况。

3. 一些常用的功能问题
   比如打印，这是Flex应用的老大难问题，能打印，但是原生的没有打印预览的功能，当然可以采用一些其他的办法来实现，但效果都不是很理想，目前只发现FlexReport的打印功能很漂亮，但是并不是很好集成。

1。C/S vs B/S 我想这个就是变成的思维和习惯问题了。如果真的要继续用flex。那就必须改变了。

关于第三点，我现在的想法是尽量让每一个页面都能生成PDF，然后在打印浏览的时候直接返回PDF文件。
然后打印PDF就行了。
现在正在试验可行性。。。

基本上是可行的，可以使用AlivePDF这样的工具转PDF很方便，如果全是英文还好，有中文的话还是有点费劲，呵呵，我们一直努力将Flex的打印解决的漂亮些，但是很困难，-.-

13 楼 Auckland 2009-11-30  

chinakite 写道

---------------------------- 我是chinakite的分隔线 ------------------------------

上面是楼主提出的问题，其实在使用过程中发现Flex带来一些其他方面的问题倒是挺另人困扰的
1. C/S结构
   C/S结构带来的第一个问题是B/S程序员思想的转变，你不能要求所有的程序员都有过C/S开发的经验。用惯了Request、Response的B/S程序员还是更习惯一个request对应一个response，使用Get或是POST方式提交request，而Flex本质上是一个C/S应用的Client端，在Client端可以保持State，这会带来很多架构和开发上的不同，例如缓存、客户端State的使用等。如果不能很好地理解做Flex应用会很别扭。

2. 全异步事件模型
   这也是思想上的事，习惯了Java的程序员更熟悉同步模型，更习惯一种命令顺序执行的开发方式，而Flex是一个全异步的事件模型，哪怕你只是弹出一个Alert也要在Alert的回调中来实现该有的逻辑。实现上是没问题，但是带来的问题一是经验较少的开发人员容易出错，另一个是本来逻辑中很顺的代码会被回调拆分的七零八落，比如一个界面需要顺序调用几个远程对象，那么你只能在A的result事件中去调用B，然后再B的result事件中去调用C……
   当然使用Ajax也是同样的情况。

3. 一些常用的功能问题
   比如打印，这是Flex应用的老大难问题，能打印，但是原生的没有打印预览的功能，当然可以采用一些其他的办法来实现，但效果都不是很理想，目前只发现FlexReport的打印功能很漂亮，但是并不是很好集成。

1。C/S vs B/S 我想这个就是变成的思维和习惯问题了。如果真的要继续用flex。那就必须改变了。

关于第三点，我现在的想法是尽量让每一个页面都能生成PDF，然后在打印浏览的时候直接返回PDF文件。
然后打印PDF就行了。
现在正在试验可行性。。。

12 楼 Auckland 2009-11-30  

wills 写道

现在让一个做Web的人去做Flex的开发可能还是那不不适应的, 正如楼上的朋友所说, 这个是编程的思想和习惯问题.
至于楼主说的几个问题我的看法是这样子的:
1.浏览器兼容性问题,这是使用FlashPlayer作为平台的最大好处,它能借助Browser的优势, 至于说actionscript + mxml不是很好,那就错了. 在Flex编程中,MXML相当Web开发中的HTML,而ActionScript则相当于Js,这跟Web开发很相似. 其实用Flex开发,就好像在用VB开发,很简单的.
5. flex 和 rails 有点像 混血儿, rails 我真没了解过, 但是我觉得flex是一个客户端程序,所以它有别于B/S开发. 至于分工的话, 服务器端只要提供纯业务逻辑就可以了,不用去控制页面, 将前端的事情都交给Flex吧. 这样的分工我认为不是混血儿, 反而更加清晰~!

1。浏览器的兼容性。这就是flex吸引我的地方之一。
2。公司有大量的遗留系统。cobol和php的。现在的努力方向之一就是分离业务逻辑，数据贮存和页面显示这三个层次。flex的优点就是尽可能的分离了业务逻辑层和页面显示层。

11 楼 Auckland 2009-11-30  

chinakite 写道

针对楼主提出的这几个问题，我的看法是：
1. 开发效率
   Flex对开发效率最大的贡献一是天然的跨浏览器支持，写程序的时候觉得很安全，不会担心不同浏览器的兼容性问题，至少可以省去一大部分精力；二是调试模式的支持，使用FlexBuilder（当然这是要花钱的）可以很方便地进行Debug，发现问题解决起来很方便；三是可以非常非常方便地扩展组件的功能，实现自己需要的组件。
   而至于说mxml还是actionscript问题都不是太大，程序员学习一种语言很容易，但是Flex目前的问题是原生的组件几乎都需要扩展才能适应复杂的应用需要，例如树形组件，我们经常会碰到需要动态加载子节点的情况，这些都需要扩展才行，而Flex内部有许多奇怪的逻辑，在扩展的时候会遇上许多陷阱，呵呵。但是我要说如果经过积累形成一套实用的组件库，开发的效率绝对非常快。
   上面都是开发效率上的优点，使用Flex开发也有开发效率下降的一方面，Flex的编译器实在是太慢了，前面的朋友说使用mxml开发界面快到另人发指，那么Flex编译的速度就慢到另人发指了，在开发一个大型应用的时候，将项目分成了多个Module，进行一次全编译的时候让我无时不想起当年开发C++手机系统的时候，编译一次要N久的时间，基本上可以喝喝茶聊聊天了，我们通常是把自动编译关掉，通常会充分利用午休的黄金编译期进行代码更新，因为代码更新一次一般都会进行一次全编译……

2. flex生成文件的大小
   这个问题还真不是很大，使用RSL方式编译，将项目分成多个Module，通常主文件会有几百K，而每个Module只有几十K，如果还觉得大的话还有其他的办法，实现自己的Module，可以将一个Module降到几K。

3. Flex的运行效率
   Flex应用的运行效率是非常另人满意的，但是要注意大页面尽量少出现横向滚动条，目前我们发现一个信息量很大动态信息较多的页面，横向滚动条会出现界面渲染慢的问题，当然运行效率的前提是客户端的内存要求，我们的应用目前需要占用120M左右。

4. Flex的SDK
   Flex的SDK不觉得有什么问题，除了它的编译器（前面说过了）。Mouse事件足够使用了，通常也用不着那么多类型的鼠标事件，单击，双击，滚轮，移动都支持对我们来说足够了。

1。 我已经很荣幸的关掉了自动编译。呵呵。至于开发组件的问题，这个真的需要自己在实践中积累了。
2。 module看来是个好东西。要自己研究一下。

其他的方面现在看来都是小问题了。

10 楼 Auckland 2009-11-30  

todn211 写道

我刚用FLEX+JAVA完成一个流程设计器，楼主提到的前四个问题根本就不是什么问题。都有相应的解决办法。至于第5个问题更加不是问题，两种语言的切换来写又怎么了，你用ruby和JS不一样要两种语言间切换吗？以上的问题都解决不了，证明你是不了解ACTIONSCRIPT.

兄弟言重了。我所说的基本上是我这几天的感受。现在我正在继续研究action script。。。。。

9 楼 wills 2009-11-29  

现在让一个做Web的人去做Flex的开发可能还是那不不适应的, 正如楼上的朋友所说, 这个是编程的思想和习惯问题.
至于楼主说的几个问题我的看法是这样子的:
1.浏览器兼容性问题,这是使用FlashPlayer作为平台的最大好处,它能借助Browser的优势, 至于说actionscript + mxml不是很好,那就错了. 在Flex编程中,MXML相当Web开发中的HTML,而ActionScript则相当于Js,这跟Web开发很相似. 其实用Flex开发,就好像在用VB开发,很简单的.
2.flex 生成的文件大小,好像每一个刚接触Flex开发的朋友都这样认为. 确实,目前的Flex生成的文件一眼看上去非常大,但是这个问题已有很多的解决方案, 比方: RSL 技术, 分步加载, 模块化处理...
3. flex 的运行速度, 我想你这里指提是ActionScript在浏览器中运行的速度吧? 这个完全不用担心,因为as3的速度不比js慢.
4. flex SDK 中的不足, Flex SDK 已足够强大了.实际项目中,除了发现少许Bug外,都能满足开发的需求.
5. flex 和 rails 有点像 混血儿, rails 我真没了解过, 但是我觉得flex是一个客户端程序,所以它有别于B/S开发. 至于分工的话, 服务器端只要提供纯业务逻辑就可以了,不用去控制页面, 将前端的事情都交给Flex吧. 这样的分工我认为不是混血儿, 反而更加清晰~!

8 楼 chinakite 2009-11-28  

针对楼主提出的这几个问题，我的看法是：
1. 开发效率
   Flex对开发效率最大的贡献一是天然的跨浏览器支持，写程序的时候觉得很安全，不会担心不同浏览器的兼容性问题，至少可以省去一大部分精力；二是调试模式的支持，使用FlexBuilder（当然这是要花钱的）可以很方便地进行Debug，发现问题解决起来很方便；三是可以非常非常方便地扩展组件的功能，实现自己需要的组件。
   而至于说mxml还是actionscript问题都不是太大，程序员学习一种语言很容易，但是Flex目前的问题是原生的组件几乎都需要扩展才能适应复杂的应用需要，例如树形组件，我们经常会碰到需要动态加载子节点的情况，这些都需要扩展才行，而Flex内部有许多奇怪的逻辑，在扩展的时候会遇上许多陷阱，呵呵。但是我要说如果经过积累形成一套实用的组件库，开发的效率绝对非常快。
   上面都是开发效率上的优点，使用Flex开发也有开发效率下降的一方面，Flex的编译器实在是太慢了，前面的朋友说使用mxml开发界面快到另人发指，那么Flex编译的速度就慢到另人发指了，在开发一个大型应用的时候，将项目分成了多个Module，进行一次全编译的时候让我无时不想起当年开发C++手机系统的时候，编译一次要N久的时间，基本上可以喝喝茶聊聊天了，我们通常是把自动编译关掉，通常会充分利用午休的黄金编译期进行代码更新，因为代码更新一次一般都会进行一次全编译……

2. flex生成文件的大小
   这个问题还真不是很大，使用RSL方式编译，将项目分成多个Module，通常主文件会有几百K，而每个Module只有几十K，如果还觉得大的话还有其他的办法，实现自己的Module，可以将一个Module降到几K。

3. Flex的运行效率
   Flex应用的运行效率是非常另人满意的，但是要注意大页面尽量少出现横向滚动条，目前我们发现一个信息量很大动态信息较多的页面，横向滚动条会出现界面渲染慢的问题，当然运行效率的前提是客户端的内存要求，我们的应用目前需要占用120M左右。

4. Flex的SDK
   Flex的SDK不觉得有什么问题，除了它的编译器（前面说过了）。Mouse事件足够使用了，通常也用不着那么多类型的鼠标事件，单击，双击，滚轮，移动都支持对我们来说足够了。

5. Flex的rails
   这个没用过，不好说了，我们的结构是Flex+BlazeDS+Spring+Hibernate

---------------------------- 我是chinakite的分隔线 ------------------------------

上面是楼主提出的问题，其实在使用过程中发现Flex带来一些其他方面的问题倒是挺另人困扰的
1. C/S结构
   C/S结构带来的第一个问题是B/S程序员思想的转变，你不能要求所有的程序员都有过C/S开发的经验。用惯了Request、Response的B/S程序员还是更习惯一个request对应一个response，使用Get或是POST方式提交request，而Flex本质上是一个C/S应用的Client端，在Client端可以保持State，这会带来很多架构和开发上的不同，例如缓存、客户端State的使用等。如果不能很好地理解做Flex应用会很别扭。

2. 全异步远程调用模型
   这也是思想上的事，习惯了Java的程序员更熟悉同步模型，更习惯一种命令顺序执行的开发方式，而Flex是一个全异步的事件模型，哪怕你只是弹出一个Alert也要在Alert的回调中来实现该有的逻辑。实现上是没问题，但是带来的问题一是经验较少的开发人员容易出错，另一个是本来逻辑中很顺的代码会被回调拆分的七零八落，比如一个界面需要顺序调用几个远程对象，那么你只能在A的result事件中去调用B，然后再B的result事件中去调用C……
   当然使用Ajax也是同样的情况。

3. 一些常用的功能问题
   比如打印，这是Flex应用的老大难问题，能打印，但是原生的没有打印预览的功能，当然可以采用一些其他的办法来实现，但效果都不是很理想，目前只发现FlexReport的打印功能很漂亮，但是并不是很好集成。

4. 不适合大量文本的应用
   Flex的界面构成是基于组件的，这跟传统的网页有很大的区别，无论是排版还是使用上。虽然Adobe还在完善Text Layout，但是并不能另人满意。

5. 与其他应用的集成
   基于HTML的系统集成其他的基于HTML的系统很容易，最惨的情况下也不过是使用iFrame来嵌入一下（SSO之类的我们这里不谈，与Flex无关），但是Flex的应用就不一样了，如果你需要集成其他的报表系统，集成其他的OA系统那就都是问题了，因为Flex与HTML页面的集成问题非常大。
   Flex应用集成其他的HTML系统更多是使用flex-iFrame方式，而这个iFrame与HTML的还是有区别的，因为使用的iFrame其实就是HTML的iFrame。这会带来什么问题呢？Flex应用还是需要在浏览器中运行的，它其实就是个swf，是嵌入在一个网页中的，在这个网页的document中它就是个Object，而嵌入的另一个iFrame是与swf平级的元素，嵌入的方式其实是在HTML中开了一个div，在这个div中嵌入一个IFrame，动态计算这个IFrame的宽和高进行模拟，而如果你需要在HTML上再弹出一些Flex的东西的话就会出现恼人的层覆盖的问题了，两个平级的层是不能嵌套的。我们目前的解决办法只能是尽量避免这种形式的交互，比如在嵌入一个HTML的地图时不要设计在地图上还要弹出Flex对话框的应用，同时如果HTML页面比较大的情况下，Flex的Menu也要注意躲开HTML区域，同时还要在界面切换的时候将iframe的div设成隐藏。
   嗯，总结一下就是——很麻烦！

6. 还有一些其他的细节问题，不写了，:)

7 楼 todn211 2009-11-28  

我刚用FLEX+JAVA完成一个流程设计器，楼主提到的前四个问题根本就不是什么问题。都有相应的解决办法。至于第5个问题更加不是问题，两种语言的切换来写又怎么了，你用ruby和JS不一样要两种语言间切换吗？以上的问题都解决不了，证明你是不了解ACTIONSCRIPT.

6 楼 vearn 2009-11-28  

Manning去年出过一本书Flexible Rails, Flex 3 On Rails 2。

楼主电驴上下个pdf版参考下

我用java做后台，一直用blazeDS

5 楼 wv1124 2009-11-27  

现在Ext吃内存很严重动不动上百M,Flex好像没有这样的问题吧，呵呵，Flex开发效率绝对超过ext，ext没有好用的工具，另人发狂，以前用过Flex做过一个项目，挺好！

4 楼 towne 2009-11-27  

web services传递xml 这种方式落伍了

最近用maven 构建了一个 基于BlazeDS 的 测试 demo

真的！ 无论从习惯还是效率来说  就一个字 舒服

3 楼 somefuture 2009-11-27  

来自新西兰的朋友啊……

2 楼 fl1429 2009-11-26  

个人 不喜欢 用 flex ，  js framework 足够了。。。

1 楼 alexma 2009-11-25  

Auckland 写道

折腾了两天了 flex 和 rails。
虽然弄出了一个还算不错的demo application。
但是还是感觉怪怪的：

1. 对于Flex带来的好处有些疑问：
   传统的rails模式是erb + javascript + css.
   在跨浏览器的问题上要下点功夫，页面的美观和动感需要用css和javascript来解决。
   而在flex中，浏览器的问题被flash彻底解决。也不要一堆乱七八糟的javascript library了。
   jquery,ext 什么什么的都省了。唯一要用的就是actionscript。
  
   我感觉这样有好处也有坏处。解决跨浏览器的问题绝对是贡献。可是写actionscript + mxml就不大好说了。
   第一个就是效率。我不知道其他大大们怎么样。至少我感觉会actionscript的人比较少。精通的可能就更少了。
   传统的css + javascript对我来讲更加通俗易懂。
   不知道有没有人对比过flex的开发效率。是不是有明显的优势？
  
2. flex 生成的文件大小。
    一个很小的demo,只有list record,add record 和简单的 form validation. 一个pie chart.
   就生成了820k 文件。如果继续下去的话，岂不是要几兆的文件了？ 

3. flex 的运行速度。
    在我的笔记本上，运行demo的速度还是可以接受的。
    可是不知道像是这种rich client application运行在thin client 或者 critx上会怎么样。
    不知道有没有人试着在低端平台运行过用flex 做的application.

4. flex SDK 中的不足
    之前好像有人在帖子里说明了一下flex现在的不足。
    好像对于一些基本的mouse event支持的还不够。
    不知道有没有人能具体讲讲。

5. flex 和 rails 有点像 混血儿。
   已经习惯了ruby 和 rails 的风格，在把自己的 model 和 conntroller 都写好了之后。再来写写actionscript 真的是很不舒服。很像一个篇文章，开篇用日文，中段用中文最后用英文总结。感觉十分十分的别扭。
不过，也许有java 和 c++ 背景的人能适应的快点吧。

最后在讲讲flex对我来讲的最大好处吧。
第一个就是跨浏览器。第二个就是它可以和各种语言很好的结合。只要通过web services传递xml,json甚至是text就可以很好的和后台程序进行交流信息。对于有多种语言环境的开发者是个救星了。

最后献上一个小小的教程：flex 3 on rails 2

没有体验过flex 和 rails 结合的人士，赶快试试看吧。

1. 写界面的时候不能用 ActionScript，用 mxml 很快，如果对美观没有要求的话，可以快到令人发指。

2. 关于生成的swf文件太大，这的确是一个问题。相应的解决办法有：采用 release 模式编译；模块化，需要的模块才下载。