3
votes

Why in Flex the code behind pattern is using the Actionscript class as a base class instead of using the MXML component for that?
I mean, instead of extending our AS3 code behind class, why we don't extend our MXML in a new AS3 class?

Using that approach seems more natural, because is a real extension, we are adding code and functionalities to our MXML base.
Using the code behind pattern is a hack to OOP, every time we add a component to our MXML we need to modify our AS3 class, that is, if we modify the child (MXML) we need to modify the parent (AS3) too.

What's wrong with the opposite code behind ("code in front"?) ?

4

4 Answers

2
votes

That's kind of why Adobe decided to redesign its component architecture and created the Spark component set and the according skinning mechanism.

In this new(-ish) philosophy you create an ActionScript class that extends SkinnableComponent or SkinnableContainer, in which you describe the behavior of your component. You can then create a skin class in MXML that defines what your component will look like (and perhaps some visual behavior, but no essential behavior of the component).

This allows for a clean separation of concerns. It's not the opposite of code-behind, but it's a different approach that works really well once you get the hang of it.

2
votes

The main reason code behind got popularity was because of the tooling. You just can't drag an AS3 based component around in the Flex Builder 3 design environment. I've tried various work-arounds, but they were all problematic. In fact it was the first thing I ever blogged about: http://www.rogue-development.com/blog2/2007/03/code-in-front/

I haven't re-tried this in Flash Builder 4. Mostly because, since then, I've come to the realization that the flex layout tool is crap, and I rarely use it. Because of that, all of my recent development has been code-in-front.

If you need to bind to a variable in your MXML, you define that variable in MXML, it's then available through inheritance in your subclass.

I'm not a huge fan of spark skinning for single-skin components. If you have a component that has exactly one visual look to it, code in front is far easier to develop with. (Skinning is perfect for components that do need multiple skins)

1
votes

"Code in front" is a more natural extension and OOP design, because we are extending our MXML with functionalities in AS3 and we don't need to change our parent every time we change our child.

But it has a proble, we can't use binding in MXML because now our MXML is our base class and we have our vars/functions in the AS3 child class.


EDIT: another problem with code in front is that you can't see your "AS3 componente" in Design Mode (not tested in FB4+ maybe it's working now). For more about this read Marc Hughes's reply.

0
votes

I think the reason for this is the legacy component architecture inherited from Flash times, where you'd drag in a black box component and at most fiddle a bit with the skin on a colours / shapes / fonts level and don't (can't) touch how it works.