Flex背后的代码相反

Question

为什么在Flex中，模式背后的代码是使用Actionscript类作为基类而不是使用MXML组件呢？ 我的意思是，为什么我们不在新的AS3类中扩展我们的MXML，而不是在课后扩展我们的AS3代码？

使用这种方法似乎更自然，因为它是一个真正的扩展，我们正在为我们的MXML基础添加代码和功能 使用模式背后的代码是对OOP的破解，每次我们向MXML添加组件时我们都需要修改我们的AS3类，也就是说，如果我们修改子代（MXML），我们也需要修改父代（AS3）。

背后的相反代码有什么问题（“前面的代码”？）？

Answer 1

这就是为什么Adobe决定重新设计其组件架构并创建Spark组件集和相应的皮肤机制的原因。

在这个新的（-ish）哲学中，您创建了一个ActionScript类，该类扩展了SkinnableComponent或SkinnableContainer，您可以在其中描述组件的行为。然后，您可以在MXML中创建一个皮肤类，用于定义组件的外观（可能还有一些视觉行为，但没有组件的基本行为）。

这样可以清晰地分离顾虑。它不是代码隐藏的相反的，但它是一种不同的方法，一旦你掌握了它就能很好地工作。

Answer 2

背后受欢迎的主要原因是因为工具。您无法在Flex Builder 3设计环境中拖动基于AS3的组件。我尝试了各种各样的解决方案，但它们都有问题。事实上，这是我写博客的第一件事： http://www.rogue-development.com/blog2/2007/03/code-in-front/

我没有在Flash Builder 4中重新尝试过这个。主要是因为从那时起，我开始意识到flex布局工具是废话，我很少使用它。因此，我最近的所有开发都是代码编写的。

如果你需要绑定到MXML中的变量，你可以在MXML中定义该变量，然后通过你的子类中的继承来获取它。

对于单一皮肤成分，我不是火花皮肤的忠实粉丝。如果你有一个只有一个视觉外观的组件，那么前面的代码就更容易开发了。 （剥皮非常适合需要多个皮肤的组件）

Answer 3

“前面的代码”是一个更自然的扩展和OOP设计，因为我们在AS3中扩展我们的MXML功能，每次我们改变孩子时我们都不需要改变我们的父母。

但它有问题，我们不能在MXML中使用绑定，因为现在我们的MXML是我们的基类，我们在AS3子类中有我们的vars /函数。


编辑：前面代码的另一个问题是你在设计模式下看不到你的“AS3组件”（没有在FB4中测试+也许它现在正在工作）。有关此内容的更多信息，请阅读Marc Hughes的回复。

Answer 4

我认为这样做的原因是从Flash时代继承的遗留组件架构，你在黑盒子组件中拖动，最多在颜色/形状/字体级别上调整一下皮肤，而不是（不能）触摸它是如何工作的。