feature request: support for subapplications

[arnoudb]

hi guys,

I was trying to load a subapplication with its own container.
But now only modules are supported with their own containers.

Of course loading a subapplication in a sibling applicationDomain would give no problems (you don't need the second parameter in the FlexXmlApplicationContext constructor) but right now we are in transition phase so the subapplications are loaded in a child applicationdomain (for reasons that go beyond the scope of this post).

Any ideas how i can best tackle this?
Is extending the FlexXMLApplicationContext is an option or would this be too complex. I mean classes inside the FlexXMLApplicationContext use the ownerModule too, so i need to extend them too, right?
I think i'll give it a go....

But the question:
What i wondered is why there is an explicit reference to the class Module in FlexXMLApplicationContext? If it would be a UIComponent or DisplayObject things become more flexible (subapps would be supported). You could define contexts like: var context:FlexXmlApplicationContext = new FlexXmlApplicationContext("context.xml", this); So nothing changes in the interface. The context will then figure out for you on which applicationdomain "this" is just like it does for modules now.

any thoughts?

Thanx!

Arnoud

[666shooter]

Hey there,

yep, I've been thinking about this as well after implemented the whole module support. Having a rootComponent makes more sense that an ownerModule, so this is definitely under consideration.
Since this is a feature and not a bug it won't make it for the final 1.0 version though.
So please add a feature request in JIRA and with a bit of luck it'll make it in the 1.1 release.

cheers,

Roland

[arnoudb]

Hi Roland,

Looking at the code you did a great job on the module system! Also it doesn't seem too complicated to change it to be more generalized.

But for the project we do now we chose to place the subapplication in a subapplication domain and skip an intermediate refactoring we planned. It should be there anyway.

In fact you support best practices (Modules in sub ApplicationDomains and sub applications in sibling ApplicationDomains) so is't definately not a must have.

cheers,

Arnoud