3

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"?) ?

Enrique
  • 4,693
  • 5
  • 51
  • 71

4 Answers4

2

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.

RIAstar
  • 11,912
  • 20
  • 37
  • Yes but why Adobe proposed code behind instead of "code in front"? and why no body is using that approach (at least I don't see it in any tutorial/guide). I mean, why the "code in front" pattern doesn't exist? what's wrong with it? I'm not using code behind, and I think I won't use "code in front" either, but I'm curious about why no body proposed it like a solution (even better than code behind). – Enrique Jun 01 '11 at 23:21
  • It seems to me that whether you code behind or in front, both classes are tightly coupled anyway. The only reason to use either approach is to separate your MXML code from your AS code. That has nothing to do with separation of concerns, it just makes your classes more readable. – RIAstar Jun 01 '11 at 23:37
  • yes, but code in front is a real extension, code behind not. We have a pure view class MXML and a pure AS3 class that extends that MXML, and hence, both classes are usable, with code behind your AS3 class (base) is not useful without your MXML, and if you change something in your child (MXML) you need to change your parent (AS3) too! maybe I'm not explaining it well, but I think there must be a reason for chosing code behind instead of code in front, this is not arbitrary, is a design pattern. Code in front must have a problem / disadvantage, but I can't see it. – Enrique Jun 02 '11 at 03:24
  • 1
    I think I found a disadvantage for "code in front", with code behind you can use binding in your MXML, with code in front you can't because your vars/functions are in AS3 and your MXML doesn't know it. Maybe that's the reason why "code in front" was never proposed like a solution in Flex. – Enrique Jun 02 '11 at 03:28
  • Good catch. That's why - before I went down the Spark road - I used to create a separate 'presentation model' and 'controller' class for each mxml component instead of using either code behind or in front. – RIAstar Jun 02 '11 at 09:34
2

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)

Marc Hughes
  • 5,808
  • 3
  • 36
  • 46
  • wow! thanks Marc, I'm not so alone now :). The Design view is an extra problem too, I didn't know that (anyway, I have not tested in FB4 either). Bue I think the most important is the binding, if you need to define the vars in MXML for binding them, then you need to add AS to your MXML (and that's is what we are trying to avoid) more if you need to bind some getter. I think both reasons are enough for code behing existence, and for not using code in front. If you want code in front, use meadiators, is a better pattern (I'm using that, but I was curious about why adobe proposed code behind). – Enrique Jun 04 '11 at 16:14
1

"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.

Enrique
  • 4,693
  • 5
  • 51
  • 71
0

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.

dain
  • 6,475
  • 1
  • 38
  • 47