Code-Behind with Flex2

Just recently, I worked on a rather large Flex2 project that went at a rather fast pace to say the least. One of the techniques that I started using were creating “code behinds” for mxml components, and man what a help that was😉 In looking back, I can’t really think of doing it any other way now. It was a much more oop way to approach component development in that I could reuse base classes for other versions of the component etc – just made it much cleaner and manageable!

Then I saw Ted’s post on it today;) It’s a great resource for getting started with this technique.

The one thing I found funny with the code behinds is the public declaration of components you’d access in MXML – that’s really the only quirk to using the code behind method (thanks to Aral for pointing that out in his white paper comments – LOL, without that little comment in the code, I’d have had no clue why mine wasn’t working)

  1. To me, there’s really no other way. It also makes it so much easier for designers to play with the view without having to sift through a bunch of code. Lots of designers are comfortable with looking at and editing markup, and the design mode doesnt feel flexible enough for them, so to me this is another very important point.

  2. Yes, that’s completely true – the designers really take to this and you really remove any worry you might have about them having inappropriate relations with your code🙂

    It’s also nice between developers – clean, neat and very easy to reuse

  3. Correct. It takes some getting used to for a lot of developers, but once they start it’s really no turning back. I’m working on two very large Flex projects right now, and this technique has been indispensible.

  4. Well, for me that is “code on top” because the component extends a base class. Actually this is just inheritance, isn’t it?

  5. I’d agree Joan this is just inheritance.

    Flex does support code behind without mis-using inheritance though through the ‘source’ property of a script tag.

  6. Yeah, and there’s a great question: what is a true code behind?

    1. using the Source tag (include) which leaves you with a file without package / class definition

    2. extending a base class like Canvas

    Personally, I don’t like the include/source idea, but Tink brought up a good question about working with designers – they’d have to look at your code to find out what type the component is. Now, that can be avoided by planning, but you could also using naming conventions or just general comments so the designer won’t have to look in your code.

    Just thinking off the top of my head really, just wonder what other’s think

    Btw- I’m not suggesting one over the other – I really think I need to work with more designers and Flex2 projects to start to see the benefits of either method.

  7. IMHO dot 1 is what I would actually call “code behind”.
    It could look ugly, but it does what it’s supposed to do: keep logic and GUI separated without leaving the class declaration.
    I’m not saying that it’s the best thing, but sure it has its place.

  8. IMHO, a problem with the current code-behind approach in Flex 2 is tht you actually double the amout of view classes just for the sake of separating AS code from MXML code (which in fact gets also boiled down to AS prior compiling). So it actually is just a matter of style (having AS and MXML separated) but it adds more bytecode to the SWF making it larger and probably more expensive performance-wise.

  9. I think a lot of use have come to the conclusion we don’t like includes, as you mentioned John, because of how we used it in prev version of Flash.

    There is really no reason to not like this method now. Extending a class does that have any advantages, but it has disadvantages of

    1. The design needing to know what your extending, or you having to know what the designer wants to extend.
    2. It ruins you inheritance.
    3. Your logic is a View class, as your View is going to extend it.

  10. Dirk – interesting about the byte code size and performance. Is that for sure or do you know?

    Tink –
    1. True – I agree with you, just don’t know if planning will help that or if it’s a real issue, but I think it’s a good point.

    2. I’m not sure I follow how it ruins your inheritance. Isn’t it true that if I create a sub class of Canvas for use with one component, that I can extend or use that same class directly with another?

    3. True

  11. Joan – yeah, I think you’re right that it obviously has its place in Flex world. I think, like I told Tink, that we’re coming off of AS2 and not using includes anymore – so there’s an instant stigma about it for me.

    However, when I first started using code behinds, this was the method I was using. I just felt dirty not having it wrapped in a package with a real home etc.

  12. Someone just posted this over on Ted’s blog about composition – which is what I was going to bring up last night with Tink, but I fell asleep😉 I tend to lean towards composition with AS2 pretty heavily nowadays – thoughts?

    “There is an alternate approach here, and that is to use ViewHelpers. Create a ViewHelper class (need not extend off anything if you dont want to ) for your View and then use composition to include it in your View. So in MyView.mxml…

    my:MyViewHelper view=”{this}”

    and in MyViewHelper you can have a strongly typed variable that holds a reference to the view

    public var view:MyView

    I find this approach better because you get better support for compile time checking and there is no need to declare propeties of the View in the Helper. Also feels more flexible. I beleive this is the approach used in Cairngorm.”

  13. The reason i say it ruins your inheritance, is that the person putting together the UI has no control over the superclass.

    ViewHelpers are a much better idea, but I really don’t see the problem with using an external AS file. It seems that it fits the purpose of what where trying to achieve perfectly.

    ou menation support fo compile time checking. You get that with an AS file, you also don’t need to declare the properties of the view in the AS file.

    A ViewHelper class is a little more flexible in that you could (if you really wanted to) implement 2 or more ViewHelpers, but that would seem a bad idea to me.

    So just to clarify, and get the terminology correct.

    ViewHelpers = composition
    Extending a base class = inheritance
    Scrupt tag and source = code-behind

  14. I believe both methods serve a different purpose and both can be used on a single view if you want.

    The ViewHelper is used to update the view without the interaction with your application model. This means it is used to update one or two propertues of your view.

    With code-behind you seperate logic and interface of your view. The only questionable about this method is if it object-oriented-wise a neat way to do it.

  15. I think you’ve ht the nail on the head there Patrick. I think because we had includes in Flash and not true OOP, since OOP has come along we feel that includes are not correct.

    I reckon we’re wrong in thinking this way. It kinda relates to a point that Darron Scahall brough up a while back about ‘No-brain’ getter/setters.

    We learnt that other languages have to use getter/setters and think that we should therefore apply it to ActionScript, but ActionScript has the ability to get round these issuesm and we should take advantage of them, not just follow the badnwagon of other languages.

    I really don’t see any fallback in applying your logic this way, except if you only wanted to extend your logic (i.e. not extend the class and the logic behind it). Obviously this wouldn’t be possible as the AS file can’t be extended, and you can’t extend in an AS file. This would be pretty infrequent I would have thought, and if so I would opt for a ViewHelper (at least this method doesn’t force your logic to be a DisplayObject). This also kind of cements the idea that this is the proper way to apply code-behnd (i.e. you shouldn’t be able to extend code, you should only be able to extend classes, which is the case).

  16. yeah, I guess I couldn’t have put it any better Tink – I don’t really like the idea of the AS source file being static like that. Almost gives me the red flag feeling of “i’ll be coming back and abstracting something here later…”

    And for that Composition (ViewHelper) would be a great solution, but then again, this is Flex2 – not AS2 and maybe I just need to realize that includes are not wrong in this situation

    Thanks for that link to Darron’s article on getters/setters – oddly enough, that’s something that’s been going around in my head lately as I’ve worked on several different projects all with different teams of developers.

  17. Ideally, we would have had partial classes. But it was really either this or nothing at all and at least what we have right now paves the way for potentially supporting partial classes in the future (not to downplay the engineering task that would take.) If you only knew how close we were to not having any code-behind whatsoever…🙂

  18. Sounds like you did battling on “code-behind’s” behalf for us Aral🙂 I think we’re all glad we have that option to be sure!

    • Jason Rubenstein
    • February 18th, 2007

    Oh man, this is going to save my butt.. thanks for blogging this!

  19. Aral, can you clarify what you mean by ‘But it was really either this or nothing at all’.

    This post talks about inheritance. Are you saying that Flex was close to not being able to use inheritance? I can’t belive that was the case as its a core part of AS 3.0.

  20. I had actually thought Aral meant the Source tag was what was almost lost

  21. I have to say, last night I did a refactor of a flex app I’m making for papervision3D and I used the code-behind method (rather than inheritance) and it did work very well.

    I think the only time I was actually reminded that my code behind was not in a package was the fact that when I was pulling methods out of it to put into another package, it wasn’t indented correctly😉 But that was it – code completion both in the MXML doc and the code behind worked beautifully.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s