Hi, Does Spring AS 2.0 support multi-module now, or maybe this fp on schedule?

[Regular]

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.

[Regular]

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

<sas:StageAutowireProcessor/>

in MXML context.
So, we need to handle the wire operation after the main swf context is OK:

                _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:

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.

[Regular]

Project source codes.ModuleTest.zip

[666shooter]

Hi there,

I'm very happy to see you getting busy with version 2.0! Thanks a lot for your thoughts!
Multi-module setups ought to be possible with version 2.0, but I admit I haven't committed any time yet to building a sample application that demonstrates to possibilities.
I'm surprised that the eventbuses don't seem to be linking up, this should be working 'out-of-the-box', topic listeners, however, should be set up manually between contexts because this is specific to any application.
I'm wondering how you were adding the childcontext? parentApplicationContext.addChildContext(childMXML ApplicationContext.applicationContext ought to do the trick.
The MXMLApplicationContext is sort of a special beast I guess, I'm going to have to take a new look at the implementation.
When I find the time I will be sure to create a sample application that will demonstrate a multi-module setup. I'll probably run into some bugs while I build this but I'll be sure to get it working. Multi-module support is one of the most important features for me to get working smoothly.
I'm not sure when I'll get round to building the sample app, this weekend for instance I won't have time at all to get behind a computer, but the next spare time I'll dedicate to SpringAS 2.0, I'll make sure to make the multi-module sample my priority.
I will keep you posted on my progress. Thanks for your understanding!

cheers,

Roland

[Regular]

In my testing

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:

core: ../context/impl/ApplicationContext
383.  public function addChildContext(childContext, settings):IApplicationContext
...
392.      if (settings.shareDefinitions) {
393.          addDefinitionsToChildContext(childContext, objectDefinitionRegistry);
394.      }

and then will trigger

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:

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

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

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

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:

/**
 * 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.

[666shooter]

Hi there,

just a heads-up to report that I have been working on refactoring quite a bunch of stuff in SpringAS 2.0. I have refactored the MXMLApplicationContext, it now directly inherits the DefaultApplicationContext, so it doesn't have an applicationContext property anymore.
This makes things a lot more transparent, the reason why it was done like that in the first place was because the DefaultApplicationContext required the rootview to be passed into its constructor.
This is no longer necessary since multiple rootviews can be added after construction. This greatly simplifies things I believe.
The multi-module support doesn't fully work yet, I'm still working on that one. The MXMLApplicationContext does feature one handy new property though: autoAddChildren.
This feature allows a parent context to automatically detect the creation of other contexts and add them as children to itself.
You can use the defaultShareSettings property to determine how the child contexts will be added. If you need different settings for different contexts you can listen for the beforeChildContextAdd event on the parent context and set the appropriate ContextShareSettings property on the event.

Like I say, multi module support isn't fully working yet. What needs to happen is that the parent context should first ignore the module that is added to the stage, wait for the child context to be created (which will be done inside the module) and then trigger that context to wire the module. I'm playing around with a few ideas there, but I hope that get something working this week.

Thanks for your patience

cheers,

Roland

[666shooter]

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

[Regular]

Hi there,
I've tested the multi-module solution. And I thought it's:
A. Simple to config and easy to use;
B. Event bus can connect to each part seamlessly now;
C. Can auto wire the presentation model without manully setting.

Still have 1 question, why each time the module created then we need to create a new event bus and set to every part but not just use the old one?

Snapshot and source codes see attachments.

Waiting for your reply. Thanks.

Merry Christmas, and happy new year!

Haixu

[666shooter]

Hi Haixu,

I'm glad to see you have your POC working! As for your comments about the eventbuses: the reason why each context has its own eventbus was to support scenario's where each module and context can operate completely autonomously from each other, not every use-case prefers a singleton eventbus across contexts. Imagine a shell application that loads plugins where the shell doesn't want a plugin to receive its eventbus events. Or both contexts might listen for the same event names which could potentially lead to strange results, so in such a scenario I believe it would be beneficial for each context to live side-by-side without getting into each other's hair, so to speak
But then again, you make a fair point that in other scenario's it is desired to have just one central eventbus for all modules and/or subapplications. Now that I thought about it I think its probably in most cases like that.
That's why I have added an extra EventBusShareKind enum value: EventBusShareKind.ASSIGN_PARENT_EVENTBUS.
As I am looking for sane defaults in Spring Actionscript I have made this enum value the default way in which eventbuses are shared, so if you update to the latest trunk (or the latest snapshot in our maven repository) you will see that your modules will receive the same eventbus instance as the parent. (the child contexts will at first create their own eventbus, but it'll be disposed once the parent's bus gets assigned).
Thanks for your insights, I'm happy that you helped Spring Actionscript become a little better

a happy new year to you too!

cheers,

Roland