Spring Actionscript 2.0 Progress Report - Part IV

Well, hello there!
Time for another progress report on the ongoing development of Spring Actionscript version 2.0. I think we're inching towards a true beta version, once I think we're feature-complete that'll happen. But not just yet. :)
So far I do encourage people to start using the library, right now within my company Stack & Heap we've been using version 2.0 in at least three of our current projects and things are running very smoothly.
Let's run through the new stuff that has been added, changed or improved.

Lazy dependency injection
This is a feature that I needed in my current project. Basically I stumbled upon a use-case where the container needed to instantiate an object that has a dependency on another object that isn't available yet at container startup.
The object in question is retrieved from the server and needs to be injected into that particular object.
Of course, its possible to just inject the instance from within the presentationmodel that performs the service call, but things get more interesting if more than one object has a dependency on the server object. And what if the server object itself needs to receive injections as well?

It would be a lot nicer to be able to just define an object definition for this server object and, once it has arrived from the server, hand it over to the container and let it handle it from there.

New Object Definition Scopes
In order to facilitate the configuration for lazy dependencies we decided to add some extra scopes to the ObjectDefinitionScope enumeration. The new scopes are:

• ObjectDefinitionScope.STAGE
• ObjectDefinitionScope.REMOTE

The first one, ObjectDefinitionScope.STAGE, was added to indicate that an object definition is associated with a stage component. (doh...) Before, we recommended to set the scope to ObjectDefinitionScope.PROTOTYPE for such definitions, to make sure the component didn't get instantiated as a singleton unnecessarily. But this new scope will hopefully add some clarity to the configuration.

The second one, ObjectDefinitionScope.REMOTE, is meant for the server objects I mentioned. So, the object definition is added to the configuration just as any other, with the exception that the scope is set to the aforementioned value:

 <sas:Object id="myServerObject" scope="remote" clazz="MyServerObjectClass"/>  

Now, after the object has been retrieved from the server (or any other origin than the container) it needs to be added to the container. For this you can use the manage() method on the application context:

 applicationContext.manage(serverObject);

The object definition that is associated with the instance will be looked up by type in the container. If no class can be defined in the configuration (because the class isn't available at startup for instance) its also possible to define the definition id as an optional argument:

 applicationContext.manage(serverObject, "myServerObject");

After this invocation any already existing object instances that have a dependency on myServerObject will be injected with the server object.

EventBus Configuration
As reported before, eventbus configuration can be added to the object definition in version 2.0. The original MXML config looked like this:

 <sas:Object id="dispatcher" clazz="MyDispatchingClass"/>

 <sas:EventRouter instance="dispatcher">  
  <sas:EventRouterConfiguration eventNames="{MyEventClass.SOME_TYPE}"/>  
 </sas:EventRouter>  

This has been simplified slightly, its now possible to just nest the event routing configuration directly with the object definition:

 <sas:Object id="dispatcher" clazz="MyDispatchingClass">  
  <sas:EventRouterConfiguration eventNames="{MyEventClass.SOME_TYPE}"/>  
 </sas:Object>  

Same works for event handling configuration:

  <sas:Object id="handler" clazz="{MyHandlingClass}">   
  <sas:EventHandlerMethod name="eventHandlerMethod"  
   eventName="{MyEventClass.SOME_TYPE}"/>  
  </sas:Object>  

That ought to make the overall configuration a little more concise and readable, I hope.

Context Customization
it is now possible swap out most of the internals of the object factory by adding custom implementations of the following interfaces to the configuration:

• IDependencyInjector
• IEventBus
• IObjectDestroyer
• IAutowireProcessor

Hopefully this will enable Spring Actionscript users to support more unusual use-cases that the default container logic isn't prepared for.

ApplicationPropertiesObjectFactoryPostProcessor
This processor is already present in the Spring Actionscript v1.0 and now ported to version 2.0. (Thanks @herrodius)
It enables the MXMLApplicationContext to inject a number of Application properties into its managed objects. The following properties are available:

• application.frameRate
• application.historyManagementEnabled
• application.pageTitle
• application.resetHistory
• application.scriptRecursionLimit
• application.scriptTimeLimit
• application.url
• application.url.protocol
• application.url.host
• application.url.port
• application.usePreloader
• application.viewSourceURL

And besides those, any application parameters will be added by name as well. So if the a parameter called myAppVar is passed into the application it will be available as an external property by the name of application.myAppVar.
To inject these values into an object add them into the configuration like this:

 <sas:Object id="myClass" clazz="{MyClass}">  
  <sas:Property name="frameRate" value="$(application.frameRate)"/>  
 </sas:Object>  

Default Definition Properties
Object definitions have, hopefully, sensible defaults. But we've added some shortcuts to enable you to change those without having to set these properties on every definition in the configuration.
The <sas:SASObjects/> element now has a number of the same properties as the IObjectDefinition which will be inherited by any definition within that config:

• autoWireMode
• childContextAccess
• dependencyCheck
• destroyMethod
• factoryMethod
• factoryObjectName
• initMethod
• isAutoWireCandidate
• isLazyInit
• parentName
• scope
• skipMetadata
• skipPostProcessors

For now this is only implemented in the MXML configuration, but naturally this will also be implemented in the XML and metadata versions.

In Conclusion
Those are the newest features (I hope I haven't forgotten any actually...), apart from those, there have been quite a number of bugfixes and optimizations. The autowiring has been sped up quite a bit, as well as the dependency checker. Furthermore, my colleague @bertvandamme fixed a particularly nasty bug in the popup injection logic which would screw up the FocusManager for modal popups. Good times! :)

I haven't gotten round to updating the Spring Actionscript 2.0 documentation yet, but hopefully I'll be able to add some more to that in the near future.

New snapshots have been deployed to the maven repository as per usual.

Here are the forums if you'd like to discuss anything in public:
Spring Actionscript forum

You can follow me on twitter: @mechhead
Or follow Spring Actionscript: @springas

Our JIRA bugbase can be reached here:
SpringSource JIRA

And that's all folks, until next time, happy coding!

cheers,

Roland

Spring Actionscript v2.0 Progress Report - part IV

So, after the release of as3commons-bytecode v1.0 (by the way, v1.1 is nearing completion already hehe), it was time to focus back on Spring Actionscript v2.0

I've been mostly busy re-setting up the site generation. We are building our documentation in the Docbook format. Its has a bit of a learning curve, but once you get the hang of it, and especially the extension points of the transformation classes, Docbook is a great choice to encode technical documentation in. For me it was important to be able to simply enclose a class name with a <literal/> element and have a custom XSLT sheet transform this to a <a href="...">Classname</a> result. With the href containing a valid link to the correct ASDoc page.
Luckily the intermittent XML format that is being spat out by the ASDoc compiler helps out here, so that saves me quite a bit of typing. We used to already have a system in place but this still required me to copy/paste the fully qualified into an xlink:href attribute. Which sucks if you have hundreds of class names strewn throughout the reference docs. But now that pain is gone :)

Anyways, once that was out of the way I added some custom xslthl extensions, so now we have some nicely highlighted code snippets as well.

And then the writing started... I've tried to re-organize the old reference docs into something with a little bit better of an overview. I hope I've succeeded...

But besides writing documentation there *have* been some small additions to the library since the last progress report. Let's see what they are.

MXML EventBus Custom Configuration

For XML configuration we described the Eventbus namespace handler to easily configure eventhandlers, interceptor, listenerinterceptors and event routers in the second progress report. In the third one we described the ICustomObjectDefinitionComponentinterface.
Using this interface we now offer some Eventbus configuration extensions for the MXML configuration.
So, to configure an Eventhandler in MXML use this MXML markup in your configuration:

<sas:EventHandler instance="metadataHandler">
    <sas:EventHandlerMethod name="handleEvent" eventName="complete"/>
</sas:EventHandler>

Where instance is the object name whose handleEvent method will be used as the eventhandler for events with the name complete.
To add a topic or topics, use the topics property:

<sas:EventHandler instance="metadataHandler">
    <sas:EventHandlerMethod name="handleEvent" eventName="complete" topics="topic1,topic2"/>
</sas:EventHandler>

For an event interceptor, add this MXML markup:

<sas:EventInterceptor instance="eventInterceptor">
    <sas:InterceptionConfiguration eventName="complete"/>
</sas:EventInterceptor>

Same applies here for topics, or topic properties, or if you want to intercept an event class instead of an event by name:

<sas:EventInterceptor instance="eventInterceptor">
    <sas:InterceptionConfiguration eventClass="{MyCustomEvent}" topics="topic1" topicProperties="myProperty,myOtherProperty"/>
</sas:EventInterceptor>

And event listener interceptor is almost the same as an interceptor, configuration-wise:

<sas:EventListenerInterceptor instance="eventListenerInterceptor">
    <sas:InterceptionConfiguration eventName="complete" topics="topic1"/>
</sas:EventListenerInterceptor>

And lastly, there is the RouteEvents markup, used to automatically send one or more specified events dispatched by a specified object through the EventBus. To configure this in MXML, use this markup:

<sas:EventRouter instance="eventRouterInstance">
    <sas:EventRouterConfiguration eventNames="busy,progress,ready" topics="topic1"/>
</sas:EventRouter>

And that's it!

Factory objects

Spring Actionscript v1.x offered the IFactoryObject to perform complex object creation and configuration for cases where XML or MXML markup was simply to verbose or unwieldy. Now Spring Actionscript v2.0 doesn't require you to implement the interface any more, you can simply add this metadata to your class:

[Factory(factoryMethod="createNewInstance")]
public class IncrediblyComplicatedObjectFactoryThatDoesNotImplementIFactoryObject {

    public function createNewInstance():* {
        var instance:IncrediblyComplicatedObject = new IncrediblyComplicatedObject();
        //creation logic ommitted
        return instance;
    }

}

Now all you have to do is add this class as an object definition to your configuration and it'll be automatically picked as a factory object by the container.

If you don't want to litter your classes with metadata, you can also use the XML configuration, to achieve this, first add the util namespace handler to your XMLApplicationContext:

xmlApplicationContext.addNamespaceHandler(new UtilNamespaceHandler());

Then add this namespace to your XML configuration:

xmlns:util='http://www.springactionscript.org/schema/util'

And finally, add this markup to the XML itself:

<util:factory
    factory-method="createNewInstance"
    class="com.myclasses.factories.IncrediblyComplicatedObjectFactoryThatDoesNotImplementIFactoryObject"
    id="incrediblyComplicatedObject"/>

Naturally, there is also the possibility to do the same in MXML configuration, use this MXML markup instead:

<sas:FactorObjectDefinition
    factoryMethod="createNewInstance"
    clazz="{IncrediblyComplicatedObjectFactoryThatDoesNotImplementIFactoryObject}"
    id="incrediblyComplicatedObject"/>

Metadata configuration

One of the disadvantages of the metadata configuration used to be that you can only add the [Component] metadata to classes that you have source code access to. It was impossible to add object definitions for Flex classes, or any other third party libraries for that matter.
Or maybe you simply dislike having all of the [Component] metadata strewn around your code base. Certainly in larger projects this might become a handicap.
Therefore I have added the [Configuration] metadata tag. This can be added to a class that functions as nothing more than a placeholder for object definition specific metadata.

Here's an example of what this class might look like:

[Configuration]
public class MyConfiguration {

    [Constructor(args="ref=objectName2")]
    [Invoke(name="someMethodName",args="ref=objectName1, value=10")]
    [Property(name="wireOnlyOnce",value="true")]
    [Component(id="processor",isLazyInit="true")]
    public var defaultAutowiringStageProcessor:DefaultAutowiringStageProcessor;
}

What this does is add an object definition for the class DefaultAutowiringStageProcessor, with object name 'processor'. It will inject the object with name objectName2 into its constructor, it will set its wireOnlyOnce property to true, it will invoke it someMethodName with two arguments: an instance of the object with name objectName1 and a value of 10. And finally, it will set is lazyInit property to true.

Just make sure that this class will get compiled into your resulting SWF by declaring it somewhere, otherwise the MetadataApplicationContext won't be able to detect it.

There will be an extension point for this as well, to be able to add custom metadata to these configurations that can add extra configuration logic to specific object definitions. But that is for the next progress report :)

Beta site is online!

And finally I am happy to annoucne that the beta site for Spring Actionscript v2.0 is now online! As you will see the reference documentation is far from complete. This is VERY much a work in progress, but as I mention this is a BETA site, with BETA software. So bear with me :)

So please, anything you download from there, please do not be surprised if it crashes, explodes or doesn't work like it says on the box. Do however play around with it, poke holes in it, and contact us with questions, suggestions, criticism and ideas.

You can find the beta site at this address: http://beta.springactionscript.org

I believe that's it for now, until the next time, happy coding!

Spring Actionscript v2.0 Progress Report - part II

As promised, here's part II of the progress report on the ongoing development of Spring Actionscript v2.0.

Let's step through the new bits and pieces that were added, some were just literally ported from v1.0, other ones were ported and slightly tweaked while even others are completely new to the fold.

Metadata processing

This has remained largely the same as in Spring Actionscript v1.x, with the exception that most Arrays have been converted into Vector.<String>, so some small refactorings will be needed should you want to port any of your processors from Spring
Actionscript v1.x projects.

Usage hasn't changed at all, simply add an implementation of IMetadataProcessor to the XML configuration and you're good to go.

Eventbus namespace handler

New in Spring Actionscript v2.0 is the Eventbus namespace handler. This allows you to configure eventbus related tasks completely in XML. Spring Actionscript v1.x only offered a metadata solution, so to listen for events on the eventbus you'd need to annotate your class with the [EventHandler]  metadata. This puts a dependency on the framework, and therefore Spring Actionscript v2.0 allows the configuration to be completely external.

Event handlers

First add the eventbus namespace to the XML:

<objects xmlns="http://www.springactionscript.org/schema/objects"
   xmlns:eventbus="http://www.springactionscript.org/schema/eventbus"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springactionscript.org/schema/objects
   http://www.springactionscript.org/schema/objects/spring-actionscript-objects-2.0.xsd
   http://www.springactionscript.org/schema/eventbus
   http://www.springactionscript.org/schema/objects/spring-actionscript-eventbus-2.0.xsd">
</objects>

To configure an object as an eventhandler, first add the object to the configuration as usual:

<objects xmlns="http://www.springactionscript.org/schema/objects"
  xmlns:eventbus="  href="http://www.springactionscript.org/schema/eventbus">http://www.springactionscript.org/schema/eventbus"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springactionscript.org/schema/objects
    http://www.springactionscript.org/schema/objects/spring-actionscript-objects-2.0.xsd
   http://www.springactionscript.org/schema/eventbus
   http://www.springactionscript.org/schema/objects/spring-actionscript-eventbus-2.0.xsd">


<object id="eventHandler" class="com.myclasses.events.handlers.MyEventHandler"/>


</objects>

Now, to configure this object as an eventhandler, add this eventbus specific configuration:

 

<objects xmlns="http://www.springactionscript.org/schema/objects"
xmlns:eventbus="  href="http://www.springactionscript.org/schema/eventbus">http://www.springactionscript.org/schema/eventbus"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springactionscript.org/schema/objects
http://www.springactionscript.org/schema/objects/spring-actionscript-objects-2.0.xsd

  http://www.springactionscript.org/schema/eventbus
http://www.springactionscript.org/schema/objects/spring-actionscript-eventbus-2.0.xsd">
 

  <object id="eventHandler" class="com.myclasses.events.handlers.MyEventHandler"/>

  <eventbus:event-handler instance="eventHandler">
  <eventbus:event-handler-method method-name="handler" event-name="testEvent"/>
</eventbus:event-handler>

</objects>

  This basically says: Use the method handler on the instance eventHandler to handle events of type testEvent coming through the eventbus.

  If you need to listen to events of type testEvent that have been associated with a certain topic, configure the topic like this:

 

<eventbus:event-handler-method method-name="handler" event-name="testEvent" topics="topicName"/>

  Its also possible that the topic is defined by one of the properties on the eventHandler instance, let's say the eventHandler instance has a property called securityToken which is also used a topic filter. You can

define this like so:

 

<eventbus:event-handler-method method-name="handler" event-name="testEvent" topic-properties="securityToken "/>

  Both attributes (topics, and topic-properties) can contain multiple entries, just as long as they're entered as comma delimited strings:

 

<eventbus:event-handler-method method-name="handler" event-name="testEvent" topics="topicName1,topicName2"/>

To listen for a specific event class, add the fully qualified class name like this:

<eventbus:event-handler-method method-name="handler" event-class="com.classes.events.MyCustomEvent"/>

Routing events

Spring Actionscript 1.x offers the [RouteEvents] metadata to automatically send certain events dispatched by ordinary IEventDispatchers through the eventbus, Spring Actionscript 2.0 now also offers XML configuration for this:

<eventbus:event-router instance="myEventDispatcher">
  <eventbus:routing-configuration event-names="testEvent"/>
</eventbus:event-router>

This sends each event of type testEvent dispatched by the instance with the object name myEventDispatcher through the eventbus.Same as the event-handler, its possible to define topics

directly or topic defined by properties on the IEventDispatcher instance:

<eventbus:routing-configuration event-names="testEvent" topics="myTopic1,myTopic2"/>

To send multiple types entered the event types comma delimited:

<eventbus:routing-configuration event-names="testEvent, testEvent2" topics="myTopic1"/>

Or if different events need to be dispatched using different topics:

<eventbus:event-router instance="myEventDispatcher">
 <eventbus:routing-configuration event-names="testEvent" topics="myTopic1"/>
 <eventbus:routing-configuration event-names="testEvent2" topics="myTopic2"/>
</eventbus:event-router>

Event interceptors

The as3commons eventbus offers ways to intercept, block or manipulate events coming through the eventbus. For more information, check out the as3commons-eventbus documentation .

To define them using XML configuration, first define an object that implements the IEventInterceptor  instance and then use mark-up like this to configure it:

<eventbus:event-interceptor instance="myEventInterceptor">
 <eventbus:interception-configuration event-name="testEvent"/>
</eventbus:event-interceptor>

Of course, this can be configured for an event class as well, with optionally topics or topic-properties attributes:

<eventbus:interception-configuration event-class="testEvent" topics="myTopic"/>

An interceptor can have multiple interception configurations:

<eventbus:event-interceptor instance="myEventInterceptor">
 
<eventbus:interception-configuration event-name="testEvent"/>
 
<eventbus:interception-configuration event-class="com.classes.events.MyCustomEvent"/>
</eventbus:event-interceptor>

Event listener interceptors

There is also such a thing as event listener interceptors, they can be used, for instance, to control the number of event listeners for a specific event or event class. The configuration for this is almost the same a event interceptors, only make sure to first define an object that implements the IEventListenerInterceptor interface. Then configure it like this:

<eventbus:event-listener-interceptor instance="myEventListenerInterceptor">
  <eventbus:interception-configuration event-name="testEvent"/>
 <eventbus:interception-configuration event-class="com.classes.events.MyCustomEvent"/>
</eventbus:event-listener-interceptor>

Configuration packs

An application context on its own contains as little custom functioanlity as possible. The only things that are automatically part of the ApplicationContext are dependency injection, autowiring, stage interception and the metada processor registration. To prevent having to type lengthy bootstrap code, Spring Actionscript v2.0 contains configuration packs.

These packs are defined by IConfigurationPackage implementations. For instance, to add the stageprocessing, eventbus, task and util namespace handlers to the XMLApplicationContext, simply invoke the XMLApplicationContext.configure() method and pass in an instance of FullXMLConfigurationPack .

var applicationContext:XMLApplicationContext = new XMLApplicationContext("application-context.xml");
applicationContext.configure(new FullXMLConfigurationPack());
applicationContext.addEventListener(Event.COMPLETE, onComplete);

That way normal users can just add the whole she-bang in one go, while the power users can pick and choose and add the specific functionality they need.

Child application contexts

Spring Actionscript v1.x enables you to add a parent context to an ApplicationContext, this functionality remains in version 2.0.

However, the idea of a context having a direct reference to its parent also goes against IoC principles, where an instance shouldn't know where to get its dependencies, it should instead just receive them. (Thanks Martin! :))

Spring Actionscript v2.0 now enables an ApplicationContext to receive one or more child contexts. They can be added using the ApplicationContext.addChildContext() method.

The advantage of having a parent->child relationship, instead of a child->parent is that the parent can decide what it will share with its child contexts. Let's first take a look at the signature

of the addChildContext method:

function addChildContext(childContext:IApplicationContext, shareDefinitions:Boolean=true, shareSingletons:Boolean=true, shareEventBus:Boolean=true):void;

So, by default the parent context will share everything with its children. It will register clones of all of its object definitions, it will register all of its singletons in the child's cache and will make sure that all of its eventbus events will be routed through its child eventbus as well.

Obviously, by setting one of these parameters to false will prevent a specific action from happening.

Its also possible to define which object definitions and/or singletons will be shared. The ObjectDefinition class has a property called childContextAccess which is of type

ChildContextObjectDefinitionAccess. This is an enumration which has the following values and related meaning:

• NONE - No access, do not share with child contexts
• DEFINITION - Only share the object definition
• SINGLETON - Only share the singleton
• FULL - Share both the definition and the singleton

This will hopefully give enough control to a developer to decide what to share and what not. If somebody has ideas on how to improve this, we'd love to hear about :)

In conclusion

Right, that's about it for part II of the Spring Actionscript v2.0 Progress Report. Like stated in the previous post, if you feel up for it, checkout the sources from SVN, use the provided maven script to create a build and start testing around a bit.

Here's all the information again:

https://src.springframework.org/svn/se-springactionscript-as/branches/2.0/spring-actionscript-core

You can use the maven pom in the root directory to create a working build of the Spring Actionscript core. It assumed you have Maven version 3.0.3 installed. All of the dependencies will copied to the target/dependencies directory.

Use mvn clean compile to create a build and mvn clean test to run the unit tests.

Either leave a comment on this blog or visit our JIRA system for any criticism, ideas or suggestions:

Spring Source JIRA

Thanks a lot for again for listening to me ramble, it is greatly appreciated :)

Happy coding!

Spring Actionscript v2.0 Progress Report

For the past several weeks we have been busy working on what will become Spring Actionscript version 2.0. The work is still in the alpha stages, but we thought it might be interesting for people to read about our progress and perhaps give us some criticism or ideas in the process.

The reasons for a complete overhaul were the following:

• More reliance on composition rather than inheritance internally
• Less memory consumption
• Asynchronous ObjectFactoryPostProcessors
• Complete separation of Actionscript and Flex dependent parts
• Refocus back to being an IoC container
• Make sure *everything* lives behind an interface
• Upgrade of the testing project to Flexunit 4 and the use of a mocking library

Making things smaller.

First of all, the Spring Actionscript core was starting to get bloated. There was the eventbus that got added, the operation API, a micro MVC architecture, etc.

We felt it was needed that the core library should be an IoC container, and nothing else. So in the last few months you may have seen quite few new as3commons projects pop up that seemed familiar. (If you're a Spring Actionscript user of course.)

Well, that's because we have been busy cutting out the bloat :) The following as3commons project have so far been created out of the refactorings in Spring Actionscript:

• as3commons-async
• as3commons-eventbus
• as3commons-stageprocessing

Of course the as3commons-reflect and -lang projects already originated from the Spring Actionscript v1.x code base.
This comes much closer to the original philosophy of Spring Actionscript which is focused on re-use. All these libraries are autonomous API's that can be used perfectly well on their own, but bundled together with the Spring Actionscript IoC container may be turned into a powerhouse. :)

Breaking things up further.

The new Spring Actionscript core itself is a pure actionscript library that can be used in non-Flex projects. i.e. springactionscript-core.swc

Any Flex specific functionality will be released as a separate .swc. i.e. springactionscript-flex.swc

Any other functionality will be released also as separate projects, that way you can pick and choose what you need for a particular project. i.e. springactionscript-mvc.swc

We will do our best to offer different kinds of packages for different needs. For instance we will release one huge master swc that contains all of the libraries, extensions and dependencies. But there will also be releases in the form of an archive filled with all the necessary .swc files.

Separating concerns in the object factory.

Spring Actionscript 1.x started out only supporting XML configurations, so all of the loading and parsing logic was in the base class of the object factory. When afterwards MXML and annotation based configuration was implemented this lead to an incredibly 'heavy' base class with quite a bit of logic that wasn't always needed in all usage scenario's.

The first thing that had to be done was to split up the object factory in functionally separate classes. The IObjectFactory now is only responsible for what its name indicates: Creating objects. It is composed however of an IInstanceCache, an IObjectDefinitionRegistry, an IDependencyInjector and an IAutowireProcessor. This immediately made unit testing a lot easier since the separation of concerns was a lot clearer by then.

The main entry point for most developers, the IApplicationContext, is now responsible for configuring the IObjectFactory. It serves as a registry for one or more IObjectDefinitionProvider implementations.

An IObjectDefinitionProvider is responsible for creating the IObjectDefinitions (the separate configuration recipes for objects created by the IObjectFactory), in the case of XML this means the loading of XML file(s) (be it external, embedded or explicit), parsing this XML and creating IObjectDefinitions from it. Each IObjectDefinitionProvider is also responsible for reporting any property URI's encountered in the configuration. These property files will afterwards be loaded by an ITextFilesLoader and parsed by an IPropertiesParser which eventually will populate an IPropertiesProvider.

The direct advantage of moving all of this logic into separate object instances is that after the configurations have been processed by their responsible IObjectDefinitionsProviders, these providers can be discarded, freeing up memory.

After the object definitions have been created each IObjectFactoryPostProcessor will be executed. These postprocessors can be used to analyze the registered object definitions and provide some extra configuration.

For instance the StageProcessorFactoryPostprocessor will search the IObjectDefinitionRegistry for implementations of IStageObjectProcessor and registers them with the IStageObjectProcessorRegistry instance that has been assigned to the IApplicationContext.

One of these IStageObjectProcessors is the DefaultAutowiringStageProcessor, which takes care of the autowiring of stage components in Spring Actionscript.

An IObjectFactoryPostProcessor can now also perform its logic asynchronously (this isn't the case in version 1.x), so a server call can be made for instance. Or, in the future, we will probably support some type of AOP system that will generate classes at runtime. These are also asynchronous processes, so the IoC container will be ready for those.

Creating the new contexts.

Now, to make use of an XML configuration the following code would be needed to get the ApplicationContext ready for use:

var applicationContext:IApplicationContext = new ApplicationContext();
var provider:XMLObjectDefinitionsProvider = new XMLObjectDefinitionsProvider();
provider.addLocation("application-context.xml");
applicationContext.addDefinitionProvider(provider);
applicationContext.addEventListener(Event.COMPLETE, onComplete);
applicationContext.load();

 To make life a little easier we will be providing the necessary subclasses of the ApplicationContext for the various types of configuration. For an application context that uses an XML configuration we offer the XMLApplicationContext. This subclass will automatically create the XMLObjectDefinitionsProvider and register it. Creating and loading would only need this bit of code in that case:

var applicationContext:XMLApplicationContext = new XMLApplicationContext("application-context.xml");
applicationContext.addEventListener(Event.COMPLETE, onComplete);
applicationContext.load();

Note: The location for an XML configuration can be of type String, Class or XML. When the loader encounters a String it will assume it is a URL, in the case of a Class it will assume it is an embedded XML file, and in the case of XML it will directly parse the provided XML object.

Subclasses for MXML, annotation and Actionscript based configuration will each have their own subclass for convenience. Mixing different types of configuration will still be possible, one needs only to add an appropriate IObjectDefinitionsProvider to the context manually. These subclasses are really meant for common usage scenarios.

Tweaking the XML dialect.

The XML configuration dialect has remained largely the same, with some additional new possibilities though.

Properties and method invocations can now be configured for members that live in a custom namespace. The and elements both have a namespace attribute now:

<property name="myProperty" namespace="http://www.mydomain.org/custom" value="myValue"/>

<method-invocation name="myMethod" namespace="http://www.mydomain.org/custom"/>

Static properties may be injected as well:

<property name="myStaticProperty" value="myValue" static="true"/>

For explicit null values the <null/> element already existed, we now also support <undefined/> and <not-a-number/>.

Any suggestions for more additions are welcome of course :)

Taking advantage of your parents.

An ApplicationContext can have another context as its parent. The nice thing about this is that a child context can inject an object that it created with an instance that is managed by its parent context. It is also possible for a child context to override certain objects by registering an object definition with the same name.

This functionality was already in place in Spring Actionscript v1.x, but Spring Actionscript v2.0 now offers a subtle bit of extra flexibility. Should a context have overridden an object, but in a certain case still need to inject the original instance present in the parent factory, the configuration can be set like this:

<property name="myComplexProperty" ref="parent.myValue"/>

In the case where there is a chain of parent/child contexts, this can even be brought higher up the chain like this:

<property name="myComplexProperty" ref="parent.parent.myValue"/>

Wiring stage components.

The way the stage autowiring processor is being added to the XML configuration has changed slightly as well. In version v1.0 you just needed to add a regular object definition like this:

<object class="org.springextensions.actionscript.stage.DefaultAutowiringStageProcessor" id="autowiringStageProcessor"/>

 In version 2.0 we have added a separate XML namespace for autowiring, which makes things slightly easier to read. (Hopefully...):

<objects xmlns="http://www.springactionscript.org/schema/objects"
         xmlns:stage="http://www.springactionscript.org/schema/stageprocessing"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.springactionscript.org/schema/objects http://www.springactionscript.org/schema/objects/spring-actionscript-objects-2.0.xsd">

    <stage:autowiringstageprocessor/>

</objects>

A custom IStageObjectProcessor can be configured like this with a custom IObjectSelector:

<objects xmlns="http://www.springactionscript.org/schema/objects"
         xmlns:stage="http://www.springactionscript.org/schema/stageprocessing"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.springactionscript.org/schema/objects http://www.springactionscript.org/schema/objects/spring-actionscript-objects-2.0.xsd">

          <object id="customSelector" class="com.classes.MyCustumSelector"/>
          <stage:stageprocessor class="com.classes.MyProcessor" object-selector="custumSelector"/>

</objects>

Where do we go from here?

If you're interested in playing around with the new library, you can. Of course we can't stress enough the fact that this is alpha code and should *definitely* not be used in a production environment. But if you're feeling adventurous and want to try things out, go ahead and check out the 2.0 branch in our SVN repository:

https://src.springframework.org/svn/se-springactionscript-as/branches/2.0/spring-actionscript-core

You can use the maven pom in the root directory to create a working build of the Spring Actionscript core. It assumed you have Maven version 3.0.3 installed. All of the dependencies will copied to the target/dependencies directory.
Use mvn clean compile to create a build and mvn clean test to run the unit tests.

So far XML configuration and stage wiring ought to be working. If you encounter any bugs or have any ideas for new functionality, please let us know!

Either leave a comment on this blog or visit our JIRA system:

Spring Source JIRA

Thanks a lot for taking the time to read all of this, we will let you know how we progress further!

Happy coding!