Unity3D Game Developer, WebGL Developer

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)

Advertisements

Share this:

Related

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.

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.

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.

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

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.

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.

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.

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

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

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.

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… 🙂

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.