Adobe Flash Builder 4 简体中文正式版 Windows版点击下载:http://g.csdn.net/5134151
Adobe Flash Builder 4 简体中文正式版 Mac版点击下载 ：http://g.csdn.net/5134152
Adobe 在线课堂：http://adobev.csdn.net/zx/index.html
Adobe平台技术峰会课程视频：http://adobev.csdn.net/
对我在InsideRIA 上发表的，关于从MXML 移动您的Flex 组件到一个AS 基地的帖子，似乎有些不同意见。那个帖子是想向读者介绍一些Flex 组件的生命周期，现在我们回过头来，首先从一个简单的MXML 组件开始，然后将之迭代成一个AS3 组件。每个代码迭代引入组件生命周期的元素。
我不得不承认，我从没期待会在评论中看到反对AS3 的言论。在构建Flex 程序时，MXML 和ActionScript 都有特定的目的。我发现，MXML 特别适合进行布局。我感觉，ActionScript 也很强大，可以让你更好地控制你编写的代码，及代码的执行，而MXML 常常会掩盖这些细节。Flex Framework 曾完整地构建在ActionScript; 里，而Adobe 工程师这么做也是有原因的。
我不是很确定，怎样来表述我对ActionScript 的支持，所以我拉了一些twitter 的朋友来帮助我。下面我罗列了五点我支持ActionScript 的原因：
1. 构建器。 在MXML ，你不能创建一个构建器方法。而监听框架周期事件。Preinitialize 事件最适合进行监听，虽然根据我的经验，creationComplete 更为常用；
2. MXML 可转换为AS3 。 MXML 由Flex 编辑器转换成ActionScript 3 。你可以通过确定-keep-generated-actionscript 编译器自变量浏览生成的源。看下代码，你会惊讶地发现它可以如此复杂。如果你从一开始就用AS3 编写，你的组件就未进行转换。我发现从一开始就使用AS3 ，那么从一开始，你的代码就“干净”了许多。
3. 执行次序清晰 ：MXML 可以让布局更为快捷轻松，但是它常常会掩盖实际发生的情况。在MXML 中，你可以确定属性，风格，和事件监听器，作为MXML 标签的属性。你什么时候设定属性？什么时候设定风格？什么时候创建事件监听器？什么时候创建子容器？MXML 掩盖了这些细节，而ActionScript 不会。
4. 调试更为简单 ：你是否使用Flex Debugger 通过代码，却只发现调试器停在一行MXML 上，而你却不知道为什么？这个过程耗费心神，因为你不知道，实际上如果你使用ActionScript, 来更新属性，更改风格，或者发送事件，这都不算什么。
5. 可移植性 ：MXML 代码与Flex 编译器连接，而AS3 代码是可移植的，可以用在别处，譬如与Flash Professional 一起使用。即使Flex Framework 也可以在没有Flex 编译器的条件下使用，不过你必须自己初始化恰当的Managers 。有很多相关的帖子。我希望以后Adobe 可以改进，从而使得与其他IDE 分享Flex Framework 组件变得更为简单，而不论是否有Flex 编译器；
6. ASDocs ：在Flex2 和3 中，MXML 不支持ASDocs 。如果你为早期的框架构建代码，你就不能用这个强大的工具记录你的API 。Flex 4 向MXML 文件添加了ASDoc 支持，但是如果你没有升级你的程序到Flex 4 ，这就是个限制条件；
7. 性能 ：MXML 可能导致过度使用容器，至少在许多程序中是这样。有些Flex Containers 可能有“昂贵”的布局程序，特别是当它们继承了层次链的所有布局逻辑之后。许多的嵌入式容器可以导致性能问题。有时候，你不需要利用这些容器，你可以创建一个简单的使用。Flex 4 Spark 通过将布局逻辑从容器中封装出来，部分解决了多种布局问题。有时候，拓展UIComponent 及尺寸和定位元素，你自己可以编出更为有效的代码。
我不想把这个文章定义为反MXML 的帖子。它的目的就是让你提高速度。在我上一篇帖子里，评论中的对AS3 的最大抱怨就是，MXML 的长期维护更为简单。在有些例子中，我认可，但是我不确定这是放之四海皆准的。我们，作为程序员的工作就是考虑到这些方法，然后在恰当的事件，根据预算和项目目标选择恰当的方法。
本文译自：
http://insideria.com/2010/05/7-reasons-to-write-in-actionsc.html
扫一扫
324
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
