为什么要在 flex 3 中使用 MXML？
我已经使用 Flex Builder 3 在 ActionScript 3 中编写了几周的内容，但从未遇到过使用 MXML 之类的东西的需要。 我用纯动作脚本编写所有布局和设计。
我不知道为什么，但当我说我正在使用 flex builder 时，许多人立即期望我编写了大量 MXML。
MXML 真的值得推荐吗？ 如果是这样，为什么我从来没有遇到过它的需要？
I've been writing in actionscript 3 using flex builder 3 for a couple of weeks now and never encountered the need to use anything like MXML. I code all layout and design in pure actionscript.
I am not sure why, but many people immediately expect me to have written a lot of MXML when I say that I'm using flex builder.
Is MXML really recommended? If so, why did I never encounter the need for it yet?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于 MXML 在构建时被编译为 ActionScript，因此可能不需要 MXML - 一切都可以在 AS3 中编码。
然而，我发现 MXML 在某些场景中使用起来更快 - 例如，应用程序中 UI 的复合组件。
如果复合组件是库类型组件（一种新型通用小部件 - 无论是基于现有控件还是完全自定义），我会使用 AS3，因为我可以获得更好的控制。 一旦发布了稳定版本，此类控件的代码将不会随着时间的推移而发生太大变化。
如果复合组件是应用程序 UI 的一部分，并且由于用户驱动的 UI 更改（例如应用程序配置面板）而更可能随着时间的推移而更改，那么 MXML 允许更快的迭代开发。 在这种变化中，您必须移动控件、更改样式等，以响应用户或营销反馈，或随着时间的推移由业务驱动的变化。
As MXML is compiled to ActionScript while building, there may be no need for MXML - everything can be coded in AS3.
However, I find that MXML is quicker to use in some scenarios - for example, composite components of the UI in an application.
If a composite component is a library-type component (a new type of generic widget - whether based on an existing control or completely custom), I use AS3 as I get finer control. The code for such controls will not change much over time, once a stable release is made.
If a composite component is a part of an application's UI which is more likely to change over time due to user-driven changes to the UI (e.g. application configuration panels) then MXML allows faster iterative development. This is the kind of change where you have to move controls around, change styling etc. in response to user or marketing feedback, or business-driven changes over time.