Hi, Does Spring AS 2.0 support multi-module now, or maybe this fp on schedule?
I'm trying to use Spring AS 2.0 as the platform of my project.
Yet the project may split into base part and several modules, and will loading dynamically on runtime.
So, I need Spring AS can automatically load the context (MXML format) and autowire the fields.
Till now, I have no multi-module samples for Spring AS 2.0, and I've tried, seems the MXMLApplicationContext can not setChildContext? and the autowired metadata can not be used in module.
So, maybe anyone can tell me if the Spring AS 2.0 have the schedule of multi-module support, and when can we suppose to use this function point? Thank U.
About multi-module and EventBus
OK, after about 1 day of testing and debuging. Finally I've done a workaround of the multi-module context applying.
And also opened the EventBus between modules.
1st, [Autowired] metadata CANNOT used in module, because I don't know how to set the parent-child relationship before the autowire opertion. So even the main swf can't use
Code:
<sas:StageAutowireProcessor/>
in MXML context.
So, we need to handle the wire operation after the main swf context is OK:
Code:
_context.dependencyInjector.wire(this, _context.applicationContext);
2nd, ApplicationContext support to treat childcontext as a EventListener and add to EventBusChain. But it CANNOT support any topic between modules. That's if U send any event to a topic, and NO module will receive this event no matter if they ARE REALLY listen on the topic.
For the sake of it, I create a new class EventAwareAppContext extends the MXMLApplicationContext, and override the function doLoad:
Code:
override protected function doLoad():void
{
DefaultApplicationContext(applicationContext).eventBus = _masterContext.eventBus;
// _masterContext = null;
super.doLoad();
}
For this, I replace the eventbus of module to the mainpart one. And after that, the IEventAware object will set the eventbus.
Really glad to see U reply me so fast
In my testing
Code:
X. parentApplicationContext.addChildContext(childMXMLApplicationContext.applicationContext)
IS OK, but MUST be moved to the event on child context completed.
And autowired will not work due to parent can not handle the child context.
If I move [X] line to the module just created, then it will trigger codes below:
Code:
core: ../context/impl/ApplicationContext
383. public function addChildContext(childContext, settings):IApplicationContext
...
392. if (settings.shareDefinitions) {
393. addDefinitionsToChildContext(childContext, objectDefinitionRegistry);
394. }
and then will trigger
Code:
flex: ../context/impl/mxml/MXMLApplicationContext
227. public function get objectDefinitionRegistry():IObjectDefinitionRegistry {
228. return _applicationContext.objectDefinitionRegistry;
229. }
yet the _applicationContext has not built.
Also I tried childContext.applicationContext = parentContext, before the childContext initialized, and it will raise another problem:
Code:
flex: ../context/impl/mxml/MXMLApplicationContext
350. public function initializeContext():void {
351. if (!_contextInitialized) {
352. if (_applicationContext == null) {
353. var rootViews:Vector.<DisplayObject> = (_document != null) ? new <DisplayObject>[(_document as DisplayObject)] : null;
354. _applicationContext = new DefaultApplicationContext(null, rootViews);
355. }
356.X _applicationContext.addDefinitionProvider(new MXMLObjectDefinitionsProvider());
...
X line will trigger
Code:
core: ../context/impl/ApplicationContext
409. public function addDefinitionProvider(provider:IObjectDefinitionsProvider):IApplicationContext {
410.X if (definitionProviders.indexOf(provider < 0)) {
...
But definitionProviders has already been set to null when in
Code:
693. protected function cleanUpObjectDefinitionCreation():void {
...
706. _definitionProviders.length = 0;
707.? _definitionProviders = null;
...
I try to comment line 707, but after that, everything is UnOK, that maybe means the child context really can not share parent's _applicationContext, and must have it's own DefaultApplicationContext. So, at last, I give up setting the childContext.applicationContext, and finally making parentContext.addChildContext when childContext is initialized.
And, the eventbus matter, U can see ApplicationContext about
Code:
core: ../context/impl/ApplicationContext
383. public function addChildContext(childContext, settings):IApplicationContext
...
389. if (settings.shareEventBus !== EventBusShareKind.NONE) {
390. addChildContextEventBusListener(childContext, eventBus, settings.shareEventBus);
391. }
MXMLApplicationContext doesn't implements IEventBusAware, in the begining, I extends MXMLAppContext with implements IEventBusAware and link the get eventBus() function to the applicationContext field's eventbus, and it then can get the message from parent, yet MUST NOT set the topic. After that, I study the eventbus code, I found that in IEventBus, the function is defined as:
Code:
/**
* Adds the given listener object as a listener to all events sent through the event bus.
*/
function addListener(listener:IEventBusListener, useWeakReference:Boolean=false, topic:Object=null):Boolean;
And, null isn't mean ANY_TOPIC, but THE TOPIC "NULL". So, link bus to each other seems will definitely lost the topic function point. So, finally, I just replace child context bus to parent contxt bus, and this is OK.
All demo codes U will see in my attachment before. Wish it will make a little help about the implementation.
And, thank you for reply me again.
spring actionscript multi-module support
Hi again,
I have finished (the first iteration) of multi-module support in Spring Actionscript 2.0. I have updated the beta site with a sample application that demonstrates the functionality and updated the reference documentation that explains the logic behind it.
Sample application:
Cafe Townsend - Multi-module sample
Sample application source:
Cafe Townsend - Multi-module sample source view
New documentation:
Reference docs
Check the section called 'Advanced context features'.
I hope this helps a little, let me know what you think about it and if you have any suggestions, criticism, etc
cheers,
Roland
