Thanks for the article. I’m a Flex newbie, just starting to explore it now with the release of the 2.0 alpha. Your suggestion to subclass mx.core.Application makes a lot of sense to me, with the aim of maintaining traditional class files and so on. I’m having a hard time implementing this effectively in my own experiments however. I’ve been through a couple of iterations exploring this so far.

My problem seems to stem from the fact that Flex compiles mxml Application files by generating a class that subclasses mx.core.Application, containing the specific properties and “methods” defined in one’s mxml file. That’s pretty cool, but there are a couple of consequences of this I haven’t figured out how to work around:

1. If I pass a reference of the mxml generated instance to another class ( a Controller for instance), I can’t type the reference specifically. I can type it as mx.core.Application, but that will prevent the Controller from calling any subclass methods on the instance. And even knowing the name of the generated subclass, I haven’t been able to successfully get the compiler to resolve the specific type.
2. If I designate a custom subclass of mx.core.Application as the mxml’s root container, it is still a generated subclass of that custom subclass that is instantiated. So any UI properties that I reference in my custom subclass don’t exist there (even if I declare them), because I am declaring them in the mxml file, and thus in the generated subclass of my custom class.

I tried rewriting your Flex 1.5 bug example from February (Fundamental bug in Flex Builder 1.5?), and couldn’t get it to work because of the second reason — neither aButton or aTextInput exist in the scope of ApplicationSubclass. Rather they exist in the generated subclass of ApplicationSubclass (in my case named FlexBuilderBug).

So as far as I can tell at this point the best I can do is to define my custom subclass just within the mxml (using an included script file to be tidy), and accept the fact I can’t specifically type it in any class I pass it as a reference to.

Am I overlooking something basic here? Based on your tutorial and your February post it seems like Flex 1.5 behaved differently. Or maybe that was just a consequence of AS2.0 being less strict in some regards compared to AS3.0 — like allowing identical (UI) properties to be declared in both a super and sub-class? I’m very curious if you have any insight into this, since I would really like to structure my code in the manner you suggest. I’ve omitted specific code examples in the interests of brevity, but would be happy to supply those if would help clarify my description of the issue.

Thank you!

Flash remoting makes it easy to use a very lightweight architecture server-side that compliments our lightweight client-side architecture in ARP.

Note, btw, that my article was written long before Flex 2 and, although the concepts are the same, there is the additional AS2 -> AS3 conversion step — at least until AS3 is available for Flash projects.

Thanks for posting this article. It will definitely come in handy when I will throw myself on Flex2 and want to migrate my MVC projects to Flex2. I am really looking for a solution where I can keep my current structure/separation of concerns, while benefitting from AS3.

I was so happy when Flex 1 came out, because it fitted me perfectly as a developer, until I saw the price tag. It made me completely ignore Flex until recently when MM announced the labs and the Flex 2 price tag.

I am still trying to understand though if I can use openAMF with AS3 as I have done until now with AS2.