7yue's Weblog

Gumbo作为下一代Flex (V4.0)的开发代号，随着6月份即将到来的Flash Builder 4和Flash Catalyst的Beta版本的开放，也会一并登上舞台。其实Gumbo作为和Flex 3 SDK并行的项目，也已经在开源社区和Adobe的共同努力下改动了很多东西，出现了很多Build，不断加入了很多新的功能。我个人也在不断关注Gumbo的变化，相对于Flex3而言，Gumbo SDK内的变动还是非常让人兴奋的。下面就让我们来讨论一下Gumbo的来龙去脉。

今天就来说一下Gumbo的开发主旨:
1. Gumbo是Flex 4（SDK,Framework,Tools)的开发代号，意思是“坚硬的粘土”，虽说code name都是由开发团队一时兴起，凭空捏造的词语，但是，我们开发者不难从其解释中看出一些端倪......简单来说，Gumbo的出现最基本的原因是Flex3要升级，要改进。这里貌似是废话......囧
2. Design in Mind，强调设计。现今Web应用之上可以发现有一些创意工作的展示是通过Flash Player的交付机制来实现的
Flex应用已经很广泛，其中大多数Flex开发人员都在使用Flex默认的皮肤样式，Halo。46%的Flex开发人员会扩展Flex样式，其中22%的开发人员会针对Flex样式做非常重要的改动。结论：并不是定制化没有需求，而是现有Flex应用体验的定制化仍面临很多困难挑战
因此Gumbo的第一个主要宗旨是将定制化Flex应用体验变的更加容易，使其成为一个简单易行的标准操作，而不是一个充满挑战的开发特例。

Design in Mind 强调Gumbo设计的需求:
提供一个组件和皮肤框架，使外部工具可以轻松参与定制工作。
调整MXML语言以支持更多的工具定制支持，并且更加容易的描述“面向体验 experience-oriented”类型的功能，比如states和transitions。
创建一个可以提升Flash Player中已经具备的功能的使用途径，并且可以通过工具来描绘关于图像资源的实现方法，比如定制皮肤等等。
Gumbo应该保留Flex 3的兼容性，就像Flex3兼容Flex2一样；一个Flex 3应用可以在Gumbo环境下重新编译，并尽量避免出现旧版本没有的错误。
Halo和新的Gumbo组件应该可以共存于一个Flex应用，甚至是一个MXML文件。一个简单的适配机制应该去实现两者的连接和协同工作，并且尽量避免文件尺寸的增加，这种适配机制应该还是自动化的。

在Gumbo中，针对Design in Mind的需求之上实现的功能：
FXG文件格式
运行时的graphics类，表示底层图形和控制
MXML语言更好的支持工具
全新的states语法
全新的Components，适合易于定制皮肤主题的模型架构要求
全新的effects和transitions
全新的布局模型，包括可指定的layout和可视化的layout支持

3.Developer Productivity，提升开发生产力。Flex已经具备大量的开发用例，现在正在要求提供更多支持客户期待那些在其他同类型语言中已经具备的功能出现在Flex中，而且SDK需要继续提升以满足成为标准平台的很多需求。
那么提升开发生产力的需求是什么？
显著提升编译器性能，包括逐步编译和全面编译环节。5倍的编译器性能提升是一个具备侵略性的目标。
添加常用的需求功能支持，比如2-way数据绑定。
Gumbo中是否实现了呢？答案是：接近。因为5倍的编译器性能提升是一个用户，社区，开发者团队共同设定的挑战，从现在的Beta Build来看，在向着这一目标不断迈进。此外，Gumbo已经加入了：数据绑定增强和AIR中的Automation操作支持。

4. Framework Evolution，框架进化。Flex框架期望随着时间的推移而变得更加成熟，并且能够充分利用和受益于Flash Player runtimes中的已经实现的功能，因此，这一点就意味着Flex框架要能够充分抓住AS3框架中的强势功能，并顺畅的引入到自己的框架中，从而增强Flash Platform的一致性。
这个部分的需求？很有挑战性：
完全支持双向的文字布局，支持Halo和Spark两种组件
支持Flash Player 10和AIR 1.5中某些显著的功能
展示全新的高保真的文字和媒体功能
Gumbo中加入了什么功能来满足这些需求？
全新的文本控件，基于Spark的RichEditableText的全新文字框架
双向文字布局支持
视频组件支持，原来的Flex VideoDisplay真是让我抓狂...

以上就是Gumbo开发的主旨，希望能对你未来在Flex上的项目开发有所帮助。有时间我们继续深入讨论Gumbo。