Flash RIA各种方案的讨论

嗯,值得反思一下.

做最擅长的事情.扬长避短.

我建议你看一下上面帖子中提到的那个swf，给出来HTML和Flash采用的建议准则。

即使是RIA时代，HTML也不会被淘汰，因为确实很多事情本来就适合用HTML解决。HTML构建一个文本性质的界面是如此的低廉，而我们可以回忆一下，过去构建一个VB界面，现在构建一个Flash界面，都不可能那么自由方便低廉。

所以RIA的方案的适合的场景是那些较少的界面切换，而每个界面里面的逻辑操作都是多步操作；

HTML的方案是较多的界面切换，而每个界面的逻辑操作都是单步操作。

因此类似Email，blog，forum这种逻辑简单，操作步骤不会很复杂的情况使用RIA实在很不划算。既然Flash RIA本来就可以嵌入HTML，干吗不让他们共存呢？

看了的。所以开始困惑。

你说得对，针对的应该是场景。

嵌套地做法应该适用于大多数网站。

另外， 用RIA也有可以离线操作好处。

真是真是
本来是我开得头 却变成两位老大的论战
搞得我不好意思了

55

我躲了几天
仔细的研究了一下Laszlo
感觉越研究越有点失望

正如Laszlo文档上写的
他们是面向开发人员而不是界面人员的

的确有强大的界面表达能力
但是如果想达到原来VB的那种程度
还是很麻烦的

所以我就停了两天 思考ROBBIN的话
是否直接用FLASH 是一个好主意呢

不必对laszlo失望，Flex也是走这种思路的。这两种思路哪种好，哪种不好，现在都很难下定论，反正是各有各的优缺点。鼓励大家都去实践一下，看看实际的反应。

laszlo/flex的思路有一个原则：脱离传统B/S软件对美工的依赖，纯粹依靠开发人员来构建软件系统。这种思路从某种程度来说，很像传统的VB/Delphi，那时候，根本不需要美工，或者美工最多提供一些图片，按钮什么的。

进入B/S时代以后，美工和开发人员的角色开始分离，美工负责UI的设计，开发人员负责开发。这种模式实际上提高了美工人员在软件开发中的地位，同时，加重了开发人员的负担。在这种模式下，开发人员不得不去学习美工需要掌握的东西：HTML，CSS。

laszlo/flex试图让开发人员在完全不需要学习Flash情况下，直接进行Flash RIA编程，这样的话，避免了前面B/S中遇到的情况，即加重了开发人员的学习负担，而实际上这些东西本来就不是开发人员所擅长的。

这种思路的出发点无疑是非常好的，特别是对开发人员来说，避免了像当年学习HTML/CSS那样去啃Flash设计，降低了Flash RIA开发的难度，提高了Flash RIA的开发效率。

但是这种思路的缺点我认为就是“挂着羊头卖狗肉”，即挂着Flash这种本来设计动画的东西来搞窗口系统编程。Flash本来是搞动画的，从本质上来说，不适合搞窗口系统，只不过Flash普及率太高，具备了Rich Client Platform的条件，于是Macromedia就急急忙忙赶着鸭子上架了。

但是我们必须看到，Macromedia公司毕竟还是一个做设计工具的公司，即使收购了Allire，其长处仍然在动画设计方面，从未在界面开发工具领域和服务器领域有什么作为。而实际上在界面开发工具领域，除了MS，就是Borland的了。Flex出来的时间也不短了，大概有快两年了吧，大家应该注意到，Flex并没有非常普及，在可以预见的将来，也难说非常普及，这恐怕不光是售价的问题，更可能是本来这种方式就不适合Flash。

据说Macromedia Flash MX 2005将重新把重点放在design方面，而这一点是Flash designer一直抱怨的方面。我认为这一步是对的，做好自己最擅长的方面才是明智的。

再说Flash ＋ AMF这种思路，是比较贴近当前B/S的方式的，即分离美工角色和开发人员角色，同时开发人员必须掌握足够的Flash的知识。以当前Flash普及的现状来看，和1999 HTML普及的状况非常类似。

那个时代，正是大把HTML美工非常吃香的年代，可以轻松拿非常不错的报酬，他们精通DW，了解HTML和CSS，个别高手精通Javascript，可以做出来非常炫的效果，但是无一例外的是，他们在往服务器端技术延伸的时候止步了，因为他们不懂HTTP协议，不懂数据库编程，只能到这一步了。

而那个时代的程序员们，都是搞VB/Delphi/PB的，精通数据库，精通编程，却对HTML非常新鲜，充满了好奇心。后来一部分程序员彻底抛弃原来的东西，从服务器端编程和客户端编程开始学起，ASP/PHP/JSP，并且学习HTML/CSS/Javascript，最终成为了B/S时代的主力；而另一部分程序员死守VB/Delphi/PB，期望依靠Delphi/PB新版本提供的HTML控件，还是依靠老办法来搞定新时代的编程，而不必去学习自己陌生的HTML/CSS/Javascript。当然最后B/S时代发展的结果大家都是知道的。

而现在Flash所处的情况高度相似：Flash设计人员非常吃香，他们精通Flash MX 2004设计工具，少数精通Actionscript的设计人员可以做出来非常炫动态效果的Flash，但是他们也无一例外在止步在Flash Remoting的地方。因为他们不懂RPC，不懂Java/dotnet，不懂数据库编程。

而当前的开发人员，都是搞J2EE/dotnet的，精通数据库，精通RPC，也精通HTML/Javascript，但是对Flash设计一无所知，却充满了好奇心。一部分程序员选择了学习和掌握Flash的道路，他们想了解和掌握Flash设计，精通Actionscript编程，再结合他们的服务器端编程的知识，来构建新时代的RIA；另一部分程序员选择了laszlo/flex的道路，这样他们就回避学习Flash/Actionscript的门槛，可以直接使用他们现在的知识储备来进行新时代的编程。

那种道路更有前途，这实在说很难断定的一个问题。单以目前Flash的性能、flex/laszlo的发展程度来说，我认为直接使用Flash AMF开发RIA更有把握一些，虽然这种方式工作量更大，显得更原始一些，对于开发人员来说门槛更高(需要学习Flash和非常精通Actionscript编程)，但是采用这种方式解决问题的手段更多，解决问题的把握更大，因为这已经算是Flash最底层的编程。可以这样说，laszlo/flex可以搞定的事情，Flash AMF都可以搞定(可能代价很高，例如你可能要自己去实现laszlo/flex封装好的组件，但是效率肯定高很多)，而laszlo/lfex搞不定的事情，Flash AMF一样可以搞定。

如果你真用eclipse + flashout + mtasc开发的话不见得会很快．
eclipse + flashout + mtasc的优势在于：
１.更为严格的类型判断，减少你出错的几率．
２．更好的调试方式　//Flashout.error("Test instance!"+Test);
３．方便的ＣＶＳ管理，使得flash的大规模开发成为可能．

但是eclipse + flashout + mtasc架构也有一些缺陷
最主要的时候你在flash里写的一些语法，在eclipse + flashout + mtasc中
是编译不过去的．
下面是我转之mmommo的blog也许对大家会有点帮助
转：＂先说说 mtasc，很多地方却是很不错：
1、变量的作用域更为合理。
2、可以在 interface 里面写 变量！（我一直想要的东西，flash 不能在 interface 里面设置 getter/setter）。
3、更好的类型判断，严格，会节约大量调试时间。
4、不可思议的速度。
5、可灵活的通过命令行以各种方式，作为编辑器的插件。

但是 mtasc 的一些缺点让我最后不得不放弃他：
1、三元操作符的支持不好，不过这个能忍受，在问号前括号。
2、没有办法些类似于下面的语句：
_root["mc"]
而必须写成：
eval("_root.mc");
麻烦，而且我有大量类似于这个的代码。
3、没有办法写 flash 本身的全局方法，我遇到没法编译 stopDrag(mc)，而只能写 mc.stopDrag()。

加上他的变量作用域的不同、更为严格的类型检查 以及一些我已经不想去研究为什么的错误，几乎我所有的类都得改，因为我几乎连一个编译正常的测试项目都没有，以上仅是我试了一个小时总结的一些简单的问题，但是这一个小时的挫折让我不得不放弃这个不错的编译器。如果要选择 mtasc，务必要在你开始一个项目之前＂

关于flash　lite目前的版本还不行只支持flash 4.0的脚本，数组,xml....是一概没有的．不过现在flash 8ball已经开始公开测试了　呵呵
flash　lite的版本也要升级到２.０相信会有不少改善：）