Flex modules and application context loading

[buftlica]

Hi there!

Is it possible to achieve an application structure based on modules where each module would have its own application context? And do you think the class instantiation for the module would function normally?

The module would have dependencies on the loading application classes defined through interfaces so I was wondering if I could depend on autowiring to inject loading application object instances based on the bean name.

And I was wondering with which method can I add the module context to the IocFacade. It seems to me that it is not possible to add context files after once initializing the IocFacade.

One more thing that worries me is the fact that the module classes and the loading application classes are in child-parent application domains and if autowiring should fail due to this (i know there has been a recent bug fix on this issue, but I still have my doubts ).

Thanks, bye!

[666shooter]

Hi there, excellent question!

Right now we're actually working on making your requested functionality an integral part of Spring Actionscript which will be included in the upcoming v0.9 release.
If you check out the trunk in SVN the required functionality is already available. One thing you have to make sure of though when you're loading modules into your application and want them to live in their own ApplicationDomain is to create their ApplicationDomain with the main ApplicationDomain as its parent.

So, a rough example in actionscript would be this:

var moduleLoader:ModuleLoader = new ModuleLoader();
moduleLoader.applicationDomain = new ApplicationDomain(ApplicationDomain.currentDomain);
moduleLoader.loadModule("myModule.swf");

That way the applicationContext of the main application will be able to autowire components inside your module, while the module can still be safely unloaded afterwards. (Since it has its own app domain).

Also available in the trunk is the possibility for an application context to have a parent context. So in a multi-module scenario you can give each module its own app context with the main application context set as its parent.
This gives you the ability to either have the main application context create or autowire your objects, or the module application context itself. We also support overriding of object definitions. So if a module context has an object definition with the same name as an object definition in its parent context, the child context will override.

If you check out the sample app in the trunk called \spring-actionscript-core\samples\multiple-modules you can see a simple example of such a scenario. The main application has a context and two modules are loaded in separate domains and have autowiring definitions defined inside their own configuration but can also fall back on the parent context.

Right, I hope this all sort of makes sense, I'll be working on a documentation section about this, I hope I'll make it a bit more clear than the above story
Anyways, just check out the sample app, I think the code and configuration speak for itself.

If you have any questions then of course we'll be glad to answer them.

P.S. since this is trunk code, please bear in mind its still rather beta. I'm using it in my current project, so I'm quite confident that it works pretty well, but should you run into any issues, please let me know a.s.a.p. so we can solve it before we have an official v0.9 release.

cheers,

Roland

[buftlica]

Great!

I was hoping that this would somehow be available. Unfortunately I can't seem to find the time to add such features myself

I had much ideas that I implemented while working with Prana and PureMVC but I don't know if they would fit in the scope of Spring actionscript framework, so I throw them here, on the ideas heap :

1. Declarative security - to define in MXML something like

<sec:Visibility target="button" role="ADMIN" />
<sec:Enabled target="button2" role="ADMIN" />

I think this is very much possible using StagePostProcessors (or whatever they are called )

2. PureMVC integration - screen startup and shutdown commands which instantiate and register all mediators, proxies, commands which are needed by the view currently being instantiated. This provides a more clear-cut lifecycle and prevents things like mediators still in memory responding to notifications, occupying memory space or returning to the same state once a new screen is needed.

3. Startup resource loading manager - all proxies that want to load something at startup implement an interface and get registered with this manager which can load in parallel or consecutive resources. Also has a splash screen and a progress bar.

4. Swf in need loading - Each swf module has an xml with a list of classes compiled. Once you try to instantiate a class that is located in another swf, that module gets loaded by the framework.

5. Much simpler localization - all I needed was one or more xml or property files and to specify them in the context. I don't want to recompile the application. I don't want to add compiler arguments. I don't want to do anything with the flex sdk. If you ask me, this infuriates me the most. So I simply made a static language helper class that loaded an xml, detected the number of languages declared and used binding to update onscreen values.

6. Application context - currently, there is no context and you cannot pass values through some static class.

7. Event listener registration and deregistation handled by the framework. Now, it's up to the programmer to be kind and clean up after themselves. But not all of us are so considerate


I don't think these ideas are supposed to be part of this thread, but maybe they provide inspiration to someone Probably this all would be better off as some spring actionscript extension.

Bye!

[666shooter]

Hi there, you make some very valid points, let me reply to them one-by one.

1. Declarative security

This is indeed available right now through the security package in SpringAS. Right now there's no MXML equivalent though, the current implementation assumes that all security configuration is done outside of the application (XML, database, etc). An MXML extension for this is very much possible, instead of having a remotecall populate the security managers it could be done through MXML declaration. We are planning a major overhaul of the MXML support after the v0.9 release. I will make sure to add the security features on the TODO list as well.

2. PureMVC integration

I'm not much of an expert on PureMVC, so its hard for me to comment on this one. The current PuremVC extensions do not support this yet? You can add a feature request in JIRA for this if you'd like:
http://jira.springframework.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10311 &sorter/order=DESC&sorter/field=priority&resolution=-1&component=10649

3. Startup resource loading manager

I know for a fact that someone has already been working on this and was planning on donating the code to our project. I'll ping the mailinglist and see what the status is.

4. Swf in need loading

This is a very tricky issue, a class loading system such as Java has would not be possible to implement in Flash since there's no way to intercept the moment of class creation. Even if this were possible you'd still need a synchronous call to the server to retrieve the required SWF. This would effectively pause you're entire application at the moment that you try to instantiate a missing class. Not very desirable I should say. The only possibility we have is to statically determine at compile-time which classes are needed and use the resource loading mechanism to pre-load all required classes.
This process could be fragmented slightly by loading parts of your application in modules, each module having potential resource dependencies which are loaded in the bootstrap cycle of the module. But other than that I'm afraid we don't have any possibilities.

5. Much simpler localization

I think the localization package in SpringAS lays the groundwork for this already, it assigns the resource values at run-time by using an IStageProcessor implementation. You can check the sample application in SVN how it works. All you need to do is create your own system to load locale data in XML format and create the ResourceBundle at runtime. The runtime ResourceBundle creation is already explained in the sample app, its really very easy, so implementing an XML loader could be done in half an hour I think. Check it out I'd say.

6. Application context

I'm not entirely sure what you mean by this, but it is already possible to inject Application settings into your object definitions. Check out this part of the docs for more info:
http://www.springactionscript.org/do...ation_settings
Is that what you meant? If not, please elaborate.

7. Event listener registration and de-registration handled by the framework.

This one has been in the works for a long time, and by 'in the works' I mean bouncing around as an idea. No concrete implementations yet. Its a very complicated issue actually, there's a lot of different ways to go about implementing this.
In the Spring Actionscript spirit it is vital that we offer only the means to perform a certain task without forcing too much of a 'way of working' or a pre-defined structure on the end-user. So coming up with a generic way for this is hard. So eventually, and probably by version 1.0, we will support some kind of mediator pattern, but how, what and why is still very much up in the air

Anyways, thanks for your thoughts and don't hesitate to give us more


cheers,

Roland

[buftlica]

This is indeed available right now through the security package in SpringAS. Right now there's no MXML equivalent though, the current implementation assumes that all security configuration is done outside of the application (XML, database, etc). An MXML extension for this is very much possible, instead of having a remotecall populate the security managers it could be done through MXML declaration. We are planning a major overhaul of the MXML support after the v0.9 release. I will make sure to add the security features on the TODO list as well.

I was specifically talking about the MXML support. But the remote objects are not invoked through MXML. MXML just declares some security settings as component properties or children for a post processor to actually use this and set component visibility/editability. The post processor would then get user information from some manager, probably the Spring actionscript security model.

This is a very tricky issue, a class loading system such as Java has would not be possible to implement in Flash since there's no way to intercept the moment of class creation. Even if this were possible you'd still need a synchronous call to the server to retrieve the required SWF. This would effectively pause you're entire application at the moment that you try to instantiate a missing class. Not very desirable I should say. The only possibility we have is to statically determine at compile-time which classes are needed and use the resource loading mechanism to pre-load all required classes.
This process could be fragmented slightly by loading parts of your application in modules, each module having potential resource dependencies which are loaded in the bootstrap cycle of the module. But other than that I'm afraid we don't have any possibilities.

I envisioned this as some spring actionscript configuration property that would be detected by custom factory preprocessors, declare the bean lazy-init and set into motion some mechanism that would fire before the bean was truly instantiated by spring actionscript. But this was just an idea, never went into realization and I do not know what kind of problems are to encounter while developing this feature.

I'm not entirely sure what you mean by this, but it is already possible to inject Application settings into your object definitions. Check out this part of the docs for more info:
http://www.springactionscript.org/do...ation_settings
Is that what you meant? If not, please elaborate.

I know about what you are saying. I am talking about a context shared between objects instantiated by spring actionscript, somewhere you could store an object under a key for another object to fetch without having to send notifications or events. I used this for user information, user roles, language settings and configuration settings so every object could fetch them thorough the application.

Thanks for the reply, will check out the rest.

Bye!

[arnoudb]

Hi joining in :-)

question, i saw the modules example and it looks good. I'm really happy that the subapplication domain issue is being addressed. But if i do something similar with custom classes it again works only if the modules are loaded in the applications current domain.

so

moduleALoader.applicationDomain = new ApplicationDomain(ApplicationDomain.currentDomain) ;
moduleBLoader.applicationDomain = ApplicationDomain.currentDomain;
moduleALoader.url = "ModuleA.swf";
moduleBLoader.url = "ModuleB.swf";

doesn't work if i add a custom class to the ModuleA context.

moduleALoader.applicationDomain = ApplicationDomain.currentDomain;
moduleBLoader.applicationDomain = ApplicationDomain.currentDomain;
moduleALoader.url = "ModuleA.swf";
moduleBLoader.url = "ModuleB.swf";

does work.
I'm using the trunk and the latest reflection lib from as3Commons

in the example in the trunk i see that a String is used in the module contexts. That is a native class so maybe not a really good example. Could someone confirm that it works with custom classes? I.e. i defined a custom class for moduleA which is compiled in (i reference it in the root) but i get the next runtime when i try to inject it via the context for moduleA:


Error: A class with the name 'nl.artim.projectx.module_a.viewmodel.HelloWorldMo delImpl' could not be found.
Are you sure the specified class has been compiled?
Look for more information on this topic here:
http://www.springactionscript.org/do...inclusion.html
at org.springextensions.actionscript.ioc.factory.supp ort:efaultListableObjectFactory/getObjectNamesForType()[/Users/arnoudbos/Desktop/development/flex frameworks svn/spring-actionscript/trunk/spring-actionscript-core/src/main/actionscript/org/springextensions/actionscript/ioc/factory/support/DefaultListableObjectFactory.as:100]
at org.springextensions.actionscript.context.support: :XMLApplicationContext/registerObjectPostProcessors()[/Users/arnoudbos/Desktop/development/flex frameworks svn/spring-actionscript/trunk/spring-actionscript-core/src/main/actionscript/org/springextensions/actionscript/context/support/XMLApplicationContext.as:210]
at org.springextensions.actionscript.context.support: :XMLApplicationContext/afterParse()[/Users/arnoudbos/Desktop/development/flex frameworks svn/spring-actionscript/trunk/spring-actionscript-core/src/main/actionscript/org/springextensions/actionscript/context/support/XMLApplicationContext.as:172]
at org.springextensions.actionscript.ioc.factory.xml: :XMLObjectFactory/_doParse()[/Users/arnoudbos/Desktop/development/flex frameworks svn/spring-actionscript/trunk/spring-actionscript-core/src/main/actionscript/org/springextensions/actionscript/ioc/factory/xml/XMLObjectFactory.as:361]
at org.springextensions.actionscript.ioc.factory.xml: :XMLObjectFactory/_loadNextProperties()[/Users/arnoudbos/Desktop/development/flex frameworks svn/spring-actionscript/trunk/spring-actionscript-core/src/main/actionscript/org/springextensions/actionscript/ioc/factory/xml/XMLObjectFactory.as:332]
at org.springextensions.actionscript.ioc.factory.xml: :XMLObjectFactory/_loadNextConfigLocation()[/Users/arnoudbos/Desktop/development/flex frameworks svn/spring-actionscript/trunk/spring-actionscript-core/src/main/actionscript/org/springextensions/actionscript/ioc/factory/xml/XMLObjectFactory.as:308]
at org.springextensions.actionscript.ioc.factory.xml: :XMLObjectFactory/_loaderComplete_handler()[/Users/arnoudbos/Desktop/development/flex frameworks svn/spring-actionscript/trunk/spring-actionscript-core/src/main/actionscript/org/springextensions/actionscript/ioc/factory/xml/XMLObjectFactory.as:258]
at flash.events::EventDispatcher/dispatchEventFunction()
at flash.events::EventDispatcher/dispatchEvent()
at flash.net::URLLoader/onComplete()


cheers,

Arnoud

[666shooter]

Hey Arnoud,

thanks a lot for bringing this issue up. Honestly, I thought I had tackled the 'classes only compiled in module' problem because in the sample app the 'InjectedTextLabel.mxml' class is only declared inside the modules.
It turned out that 'regular' classes included in the module still triggered the exception. (When retrieving class information in that scenario the current application domain wasn't taken into account).
I think I've cleared matters up right now, at least my tests are working at the moment
I have added a sample of a 'regular' class inclusion in the sample app.

Changes are available in the trunk, if you'd like to take this for another test drive than I'd be most obliged.

Cheers!

Roland

[arnoudb]

Hi Roland,

you are a machine! damn that was fast. I'll give it another try. I'm also curious how the reverse will go.

For example a class defined in the application domain but also used in the container of a module that is loaded in a child domain.

I'll let you know about my findings. First have to get the damn project to compile again. I screwd some things seriously up

thanx!

[666shooter]

Hey Arnoud,

me and Christophe have been toying around with this concept a lot today and bumped into quite a few issues along the way.
I believe we've tackled the main ones, but it'll be much appreciated to see others test it out, so your results will be welcomed. Be sure to grab the very latest trunk source though, we've had quite a few updates today.
Your example of a class defined in the main application domain yet instantiated by a container in a child domain ought to work, just as long as the module receives an application domain that has the main domain set as its parent.
That way first the child domain will be searched for a class definition and if not found the parent domain will be used.
This same principle is also valid for how the container hierarchy works. If a container is created, and has a parent container assigned, it will first try to create a requested object itself, and if it misses the appropriate definition the parent container is used.

Anyways, play around with system as much as you can, we are very interested in your results and appreciate the time you invest testing it.

cheers,

Roland

[arnoudb]

Hi Roland,

Soory for the late reply. Really busy atm, but i think i'll have some spare time the next weekend to give it another go.

i'll post the results.

Arnoud