I code therefore I... blog?

Spring Actionscript 2.0 Progress Report - Part V

2011-12-13T11:38:00.000-08:00

Its been quite a while since the last progress report, I'm sorry to admit that I haven't been able to spend as much time working on Spring Actionscript 2.0 as I had hoped. Sadly, work and life in general got in the way.
Nevertheless there have been some exciting changes to the code base. Not a lot of extra features, but more a refinement of the existing stuff.

Multiple root views

An application context used to be only tied to one root view. I was, wrongfully, under the impression that a context will always be wiring one module or sub application.
Until I ran into a situation during my own current project where a tab navigator was managed by a parent context with child contexts managing the actual screens in each tab. Only it was possible for multiple tabs to be managed by the same child context.
So, to support this the application context now receives an optional Vector of DisplayObjects as a constructor parameter. After context creation its also to possible to add root views at runtime using the new addRootView() method on the application context. So the views do not necessarily need to be known at the time of creation of the context.

MXMLApplicationContext cleaned up
Admittedly, the MXMLApplicationContext had turned into a bit of a mess. The MXML component acted as a sort of wrapper for an internal DefaultApplicationContext, which somehow seemed like a good idea at the time but lead to nasty issues in practice. (Thanks to this forum post I realized the error of my ways: Spring Actionscript forum link)
So, the MXMLApplicationContext got refactored heavily and while fine-tuning the multi-module support I added some nifty extra possibilities for child contexts.
Originally, as described in Progress Report Part III, the addChildContext() method signature looked like this:

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

This now has changed to a slightly more readable form:

function addChildContext(childContext:IApplicationContext, settings:ContextShareSettings=null):IApplicationContext;

As you'll see the most interesting parameter here is the one called settings. This parameter is of type ContextShareSettings and this can describe the various ways that a parent context will share its data with a child context. This class has four properties:

shareDefinitions - If true all definitions that do not have their childContextAccess set to NONE or SINGLETON will be cloned and added to the child context.
shareProperties - If true all the external properties will be added to the child context
shareSingletons - If true all of the singletons in the parent's cache will be added to the child's cache, provided that an object with the same name doesn't already exist in the child context. Using this also explicitly added singleton can be shared (an explicit singleton means a cached object that doesn't have a corresponding object definition)
eventBusShareSettings - This property is of type EventBusShareSettings, which describes the way that the context eventbuses will be linked to each other.

An EventBusShareSettings instance has these properties:

shareRegularEvents - If true, all regular events, so events that are dispatched without a topic will be shared.
sharedTopics - A Vector of topics whose events will be shared.
shareKind - This property is of type EventBusShareKind as described below.

The EventBusShareKind enumeration has these values:

NONE - The eventbuses will not be connected.
BOTH_WAYS - Events dispatched by the parent will be routed to the child's eventbus, and vice versa, events dispatched by the child will be routed to the parent.
CHILD_LISTENS_TO_PARENT - Events dispatched by the parent will be routed to the child's eventbus.
PARENT_LISTENS_TO_CHILD - Events dispatched by the child will be routed to the parent's eventbus.

Some events were added to this process as well, the application context now dispatches four types of ChildContextEvents:

AFTER_CHILD_CONTEXT_REMOVE
BEFORE_CHILD_CONTEXT_REMOVE
BEFORE_CHILD_CONTEXT_ADD
AFTER_CHILD_CONTEXT_ADD

The names speak for themselves, but the most interesting ones are the BEFORE_CHILD_CONTEXT_ADD and BEFORE_CHILD_CONTEXT_REMOVE.
These events are cancelable, so when preventDefault() is called on them the specified logic will not be executed. So in these cases the child will not be added, or not removed.

Multi-module support and automatic child context detection
The Flex extensions for Spring Actionscript have been further fleshed out in the multi-module support department.
The MXMLApplicationContext has a new property called modulePolicy that determines what a context will do when it encounters a Flex module on the stage. This modulePolicy is an enum with two values:

AUTOWIRE - Try to autowire the module
IGNORE - Do nothing

By default this property has a value of ModulePolicy.AUTOWIRE, so if your application just needs one context and configuration, but loads its UI in parts there is nothing to be changed. Just add an MXMLApplicationContext and you're good to go.
However, when modules are loaded with their own context that is responsible for wiring the module, set this property to ModulePolicy.IGNORE.

Also new in this drop of Spring Actionscript 2.0 is the fact that MXML based contexts now automatically can detect the creation of child contexts. So all that is needed is to add a context to your module and things will get sorted automatically.
When a new context is detected it will be automatically added to the parent context. The way that an application context determines whether it is a parent context or a child context is by checking the systemManager's isTopLevelRoot property of one of its root views. If this property is true then it assumes its the parent, if not, it assumes its a child.
When a parent adds the child it, naturally, invokes its own addChildContext() method. To specify the ContextShareSettings instance for this call it is possible to do so using the defaultShareSettings property on the MXMLApplicationContext.

If different settings are needed for different childcontexts there is the ChildContextEvents, when listening for the BEFORE_CHILD_CONTEXT_ADD event it is possible to assign a ContextShareSettings instance to the ChildContextEvent.shareSettings property,
If the ContextShareSettings instance is not capable of describing the way that the contexts ought to be shared there is event the possibility to completely override the sharing logic.
This is done by assigning a Function to the ChildContextEvent.customAddChildFunction property, this function needs to have this signature:

function(parentContext:IApplicationContext, childContext:IApplicationContext, settings:ContextShareSettings);

A sample application that demonstrates the functionality described above here can be viewed here:

Cafe Townsend - Multi-module implementation

The application has 'view source' enabled so its implementation can be checked out easily.

Oh, and before I forget, this functionality can be turned off completely by setting the autoAddChildren property on the MXML context to false.

Popup and tooltip wiring
The MXML based contexts are now able to automatically detect popups and tooltips for wiring purposes. So it is no longer necessary to register a popup after creation, it is automatically picked by the regular stagewiring.
There was some dirty hacking needed to get this working, if you're interested in the nasty details, then check out the PopupAndTooltipWireManager class.

Logging
The framework now reports its internal behavior much more elaborately than before, its not completely finished yet, but there is already an enormous slew of statements waiting for you to be checked out.
Internally we use the mighty as3commons-logging library by Martin Heidegger which, as it should, is turned off by default.
To see the log statements turn up in your trace log all you need to do is add this line of code before the context gets initialized:

LOGGER_FACTORY.setup = new SimpleTargetSetup(new TraceTarget());

(Don't forget to add the as3commons-logging .swc to your project of course)
The as3commons-logging library offers a host of other logging targets as well, check out its documentation for more details on that.

In conclusion
The documentation has been added to steadily, you can check this out at the usual location:
Spring Actionscript 2.0 - Beta docs

New snapshots have been deployed to the maven repository, so using the 2.0-SNAPSHOT artifact will get updated automatically, should you be using that.

If you have any questions or suggestions, check out the user forums:
Spring Actionscript forum

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

Our JIRA bugbase can be reached here:
SpringSource JIRA

Thanks for taking the time again to plow through this pile of text, until next time, happy coding!

Roland

Spring Actionscript v2.0 Progress Report - part IV

2011-09-19T13:06:00.000-07:00

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!

Released: AS3Commons-Bytecode version 1.0!

2011-09-14T04:51:00.000-07:00

So, its been more than a year in the making. If I check the changelog, the first commit of as3commons-bytecode was done at the 27th of June 2010.

http://www.as3commons.org/as3-commons-bytecode/index.html

I've decided to call this release v1.0. I could think of another thousand things to be tweaked and improved but at a certain moment there needs to be a first final release :)

This certainly doesn't mean the library is now finished, I will keep on tweaking and improving the library. Hopefully users of the library will join in the discussion and suggest new features or improvements.

So, now perhaps is the time to look back, reflect and tell a little about the history of as3commons-bytecode :)

I started as3commons-bytecode after taking over the Loom project from Maxim Porges (http://code.google.com/p/loom-as3/). I had begun implementing an AOP solution for Spring Actionscript, first focusing on the pointcut scanning logic because I was following Maxim's progress with Loom and thought this would be an ideal library to use as its foundation.

Sadly, before the library was finished Maxim couldn't offer the personal resources anymore to continue the project. This certainly threw my schedule off :) At first I considered using the FLemit and FLoxy libraries but found that they were too specifically aimed at generating mocks. I need something more generic.

So that's when I started spelunking through the Loom code and step-by-step I actually started to understand what was going on. Before, I was very reluctant since I considered this stuff way beyond my mortal understanding. But I managed to fix some bugs and that's when I contacted Maxim and asked him if it was alright for me take over the project and bring it into the AS3Commons project.

Luckily Maxim was alright with this and so my nightmare begun haha :)

First thing I implemented was the bytecode based reflection. Since it appeared to be relatively simple and was a good way for me to get to know the code base a little. When this was done I started the task of finishing the parsing of all of the opcodes since this hadn't been completed yet. This was when the proverbial shit hit the fan because this is when I started to find out about subtle AVM documentation errors. Or just plain non-existent documentation...Luckily, a trip through the Tamarin source code offered quite a lot of valuable insight as well.

Actually getting the opcode parsing completely to work only got finished a few weeks ago :)

Next step was to generate classes at run-time. I was familiar enough with the ABC format by now to come up with an API to let a developer assemble an ABC file without needing to have any intimate knowledge of 'what lies beneath'. I actually used the .NET System.emit namespace as an inspiration.

Around the time that class generation was implemented, James Ward contacted Maxim Porges to see if he could persuade him to continue his work on Loom since James and Michael Labriola had been hacking away on a mechanism that could intercept SWF loading by the Flash Player.

An ideal hook for AOP and other black magic.

Maxim then forwarded James to me and afterwards Michael and James offered some invaluable help and advice in further developing as3commons-bytecode. Eventually this culminated in their Mixing Loom project (James' blog introduction) and their fantastic session called 'Planet of the AOPs' at the 360|Flex conference in Denver. This was the first true introduction of AOP to the Flash community I guess you could say.

After class generation was working the next step was to provide a generic API for generating dynamic run-time proxies. These are basically subclasses (generated at runtime) that incorporate an interception mechanism for methods and accessors (getters and setters). So when a method gets invoked on the dynamic subclass it will first invoke any registered interceptors, enabling these interceptor to perhaps change or replace the behavior of the underlying functionality. Most mocking libraries (like asmock, mockolate or mockito-flex) are based on this logic.

The API for this is explained in this documentation section on the as3commons site.

Naturally, the most interesting solution that can be created using this proxy API are AOP mechanisms and quite soon after the proxy API became available Marty Pitt went ahead and created Flapper. An AOP extension for the Parsley framework. As if this wasn't enough, he then also created another library called Dynamic Services, also a Parsley extension. This library is able to take an interface that describes a service class and generate this service on-the-fly. This can save you a lot of typing :)

David Arno discovered the library as well and went out to create AS3Introspection, a library that he himself dexcribes as "describeType on steroids". I think that pretty much covers it :)

Jeff Ardillo then went ahead and showcased a technique to create proxies without having to depend on the ProxyFactory to create them in his excellent blog article 'Aspect Oriented Programming in Flex'.

I am very excited to see all of these initiatives take shape as this is exactly the reason why I started as3commons-bytecode. It was its specific aim to be a foundational library and facilitate a platform for other developers to base their own solutions on. Seeing this actually taking place is very satisfying indeed, so kudos to all of you who have taken the library to its next level!

Lately the Flash/Flex twitter- and blogosphere has been buzzing a lot with all sorts of AOP solutions. The Swiz framework just announced their own AOP functionality in their upcoming version 2.0, for instance. This is all great news and opens up all sorts of new and exciting possibilities on the Flash platform.

In that spirit, expect to see a new As3Commons project to be released in the near future as well. It'll be called as3commons-aop and will offer a bunch of standard interfaces and API's that deal with advices and pointcut scanning. Hopefully this will help developers to easily incorporate AOP functionality in other frameworks out there. As we are used to eating our own dogfood, Spring Actionscript will naturally use as3commons-aop as its AOP foundation :)

Yet, I would like to stress, don't focus only on the AOP possibilities of as3commons-bytecode. I believe that projects like Marty Pitt's Dynamic Services show that much more can be achieved with the ability to generate classes at run-time. So be creative and try to come up with some more interesting solutions!

Thank you very much to everyone who has submitted bug reports, feature requests and developed solutions based as3commons-bytecode!

Happy coding!

P.S. If you'd like to get involved with as3commons-bytecode's development or the as3commons project in general, please drop us a line! We always appreciate more help and contributions!

Spring Actionscript v2.0 Progress Report - part III

2011-09-04T09:41:00.000-07:00

We're gradually getting ready for a first beta release. Most of the foundational parts of the IoC container have now been refactored and unit tested. (Although the unit testing is still an ongoing process)
Spring Actionscript 2.0 was put on the backburner just a little bit the past week since a bunch of debugging work for the AS3Commons-Bytecode library took up just a little bit more time than was anticipated... Apologies for this. (But expect a new AS3Commons-Bytecode release as well in the coming days :))
In the past few weeks the following has been added:

IMetadataDestroyer interface

To be able to undo the processing of an IMetadataprocessor a second interface has been added. Its much like the IStageObjectProcessor and IStageObjectDestroyer logic. One performs certain logic, the other is able to undo this logic in case this is necessary. The interface is quit simple:

public interface IMetadataDestroyer {
  function get metadataNames():Vector.<String>;
  function destroy(instance:Object, container:IMetadataContainer, metadataName:String, objectName:String):void;
}

MXML Application context

Besides the XML based configuration, naturally, the MXML based configuration makes its comeback as well. It has changed slightly compared to the one in Spring Actionscript 1.x, but the changes aren't enormously disrupting.
The MXMLApplicationContext itself is now also an MXML element, so here's how its declared in an application:

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
   xmlns:s="library://ns.adobe.com/flex/spark"
   xmlns:mx="library://ns.adobe.com/flex/mx"
   xmlns:sas="http://www.springactionscript.org/mxml/config"
   creationComplete="application1_creationCompleteHandler(event)">
<fx:Declarations>

<sas:MXMLApplicationContext configurations="{[TestObjects]}"
configurationPackage="{new FullConfigurationPackage()}"
id="MXMLContext"
autoLoad="true"
complete="{onComplete(event)}"/>


</fx:Declarations>
</s:Application>

As you can see, the configuration is fed to this Application Context usingits 'configurations' property, which accepts an Array of Classes. In this casethe TestObjects class is also an MXML file and looks like this:

<sas:SASObjects xmlns:fx="http://ns.adobe.com/mxml/2009"xmlns:s="library://ns.adobe.com/flex/spark"xmlns:mx="library://ns.adobe.com/flex/mx"
xmlns:sas="http://www.springactionscript.org/mxml/config">
<fx:Script>
<![CDATA[
import classes.MetadataHandler;

import mx.collections.ArrayCollection;
[Bindable]
public var collection:ArrayCollection = new ArrayCollection(['value1', 'value2']);
]]>
</fx:Script>
<fx:Declarations>
<sas:Object id="test"
clazz="{Object}">
<sas:Property name="list"
  ref="collection"/>
</sas:Object>

<sas:Object clazz="{MetadataHandler}"
id="metadataHandler"/>
</fx:Declarations>

</sas:SASObjects>

The object definitions haven't changed at all from Spring Actionscript 1.x, apart from the extra properties that were described in part I of the progress report. As you can see, it's also possible to just declare regular object instantiatons in the configuration and have them being treated as singletons in the context. For instance the ArrayCollection called collection can be retrieved from the ApplicationContext simply by invoking MXMLContext.getObject('collection');.
As you can also see, the collection singleton is also being injected into the object called 'test' in its property called 'list'.
Naturally, MXML object such as RemoteObject can also directly be declared inside the configuration, without having to resort to creating an <Object/> element for it. Direct declaration only works for singleton of course.
The MXMLApplicationContext is, like the XMLApplicationContext, nothing but a convenience subclass. It also very much possible to construct one manually like this:

var applicationContext:DefaultApplicationContext = new DefaultApplicationContext(null, rootView);
var provider:MXMLObjectDefinitionsProvider = new MXMLObjectDefinitionsProvider();
provider.addConfiguration(TestObjects);
applicationContext.addDefinitionProvider(provider);
applicationContext.addEventListener(Event.COMPLETE, handleComplete);
applicationContext.load();

ICustomObjectDefinitionComponent interface

Similar to namespace handlers that make the XML configuration a little easier to read, the MXML configuration can contain ICustomObjectDefinitionComponents. Implementations of this interface can define a custom configuration for a certain type of object and offer a few shortcuts for this configuration. The interface is quite easy again:

public interface ICustomObjectDefinitionComponent extends IMXMLObject {
  function execute(applicationContext:IApplicationContext, objectDefinitions:Object):void;
}

Once the MXMLApplicationContext starts loading its MXMLObjectDefinitionsProvider and encounters an ICustomObjectDefinitionComponent, it will invoke its execute() method and pass in a reference to the MXMLApplicationContext and its objectDefinitions instance.
The objectDefinitions instance is an anonymous object that serves as a Name->IObjectDefinition lookup for the definitions
that are created by the MXMLObjectDefinitionsProvider. So an ICustomObjectDefinitionComponent implementation can just add its own
definitions to this instance.
No implementations are yet available in Spring Actionscript 2.0, but we're planning to create some shortcuts for the eventhandling and interception, similar to the XML shortcuts described in part II of this progress report.

Metadata Application Context

Lastly, there is the MetadataApplicationContext, which does exactly as its name suggests: It creates ObjectDefinitions that are defined in metadata. This ApplicationContext needs to have its rootView set, this is because it uses this rootView to resolve the correct loaderInfo reference which is used to scan the SWF's bytecode for the necessary metadata annotations. So, if the MetadataApplicationContext is part of a regular application, this would suffice:

var context:MetadataApplicationContext = new MetadataApplicationContext(Application(FlexGlobals.topLevelApplication));
context.addEventListener(Event.COMPLETE,onComplete);
context.load();

The metadata hasn't changed, you can check out the existing doc sections for
it: Spring Actionscript Component Scan.
Only one addition has been made actually, it is now also possible to define an external properties file in metadata. To do so annotate any class in your project with the following metadata:

[ExternalProperties(location="properties.txt")]
public final class ConfigurationClass {
}

Naturally, you can also add required='true' or preventCache='false' to the metadata arguments.

spring-actionscript-flex.swc

As promised, all Flex specific functionality is now part of a separate .swc.
So in order to use the MXMLApplicationContext you will need to add the spring-actionscript-flex.swc to your library path. The library also offers some extra namespace handlers that target flex specific classes. So in order to easily use those they have been packaged in an IConfigurationPackage implementation called FullFlexXMLConfigurationPackage.
As described in part II of this progress report, you can add such a configuration package using the configure() method on the application context:

var context:XMLApplicationContext = new XMLApplicationContext();
context.configure(new FullFlexXMLConfigurationPackage());

Creating a build

The SVN repository has changed a little bit, so in order to create your own beta build things have changed slightly. First, check out this directory from the Spring SVN repository:

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

In the checked out directory simple run this maven command: mvn clean compile in order to create a build.
Run mvn clean test to run the unit tests.
You will find the spring-actionscript-core and spring-actionscript-flex .swc's in their respective subdirectories. (spring-actionscript-core/target and spring-actionscript-flex/target)

In the near future...

Next up there's still a number of unit tests to be ported from Spring Actionscript 1.x. After that the documentation site will be overhauled. The current site is very rich in information but we feel it needs to be organised better into smaller bite-sized chunks that might be easier to digest for developer's who are new to the framework.
So we'll try and make a couple of 'Getting started' pages without immediately throwing every detail of the framework into the casual reader's face.
We'll try and get http://beta.springactionscript.org up and running as soon as possible.

In the further future...

We are in the planning stages of AOP support. In the past year we have been working hard on as3commons-bytecode which is the library that provides the most low-level support for AOP functionality, namely the creation of dynamic proxy classes and the dynamic manipulation of existing classes.
Next we will release an as3commons project called as3commons-aop which will provide a foundational library offering advice and aspect interfaces, a pointcut scanning system combined with an expression dialect. The template for this will naturally be Spring AOP, but we will try to make the foundational library framework agnostic enough so that other frameworks might use it as well.
This AOP library will then be used to implement the eventual Spring Actionscript AOP support.
All of this is a huge task which is mostly done in our spare time, so naturally we can't give you any release schedule... :)
Any help, however, is always welcome. So if you feel up for it, contact us either at as3commons.org or springactionscript.org (depending on what you'd like to do) and we'll see how we can help eachother out.
And like previous posts, we'd love to hear feedback from you. So any criticisms, ideas, suggestions are more than welcome.

Happy coding!

Spring Actionscript v2.0 Progress Report - part II

2011-08-22T12:45:00.000-07:00

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

2011-08-18T12:12:00.000-07:00

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:

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

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!

AS3Commons-Bytecode v0.9.2 released

2010-12-29T09:41:00.000-08:00

The last two days two updates to AS3Commons-Bytecode were released, v0.9.1 and today v0.9.2 to be precise.

The most important additions in these two releases have been the support for proxying protected and custom namespace members. I ran into a bunch of issues during development but wanted to get the API out so that people could play around with it and perhaps come up with some constructive criticism. Therefore the first v0.9 release only supported public members, enough for some basic testing and trying out.
Luckily in the past few evenings I've been able to track down the issues I had surrounding generation of protected and custom namespace scoped members.

It came down to a few bugs in the Bytecode reflection and emit.* API, that'll teach me to unit test better I suppose. :)

Another handy addition are a bunch of build cycle events that allow a developer to customize the generation of the method bodies. All of them are explained in this doc section:
Generating the proxy classes

Furthermore, the library now offers an entry point for using an IFactory implementation to take care off the creation of IMethodInvocationInterceptors. How this is hooked up is described in this section:
Instantiating a proxy class

For the next release I'll be focusing on what they call in AOP terms 'introductions', which means that the library will enable you to let proxy classes implement new interfaces at runtime. Handy for when an object needs an 'isDirty' property, for instance.

When that's finished I suppose a version 1.0 should be ready.
Beyond v1.0 will be bytecode weaving based AOP, this is going to introduce its own set of difficulties to overcome which is why I've decided to push it back after the v1.0 release.

Cheers and a happy new year!

Roland

AS3Commons-Bytecode v0.9 released

2010-12-26T14:19:00.000-08:00

Today saw the release of v0.9 of AS3Commons-Bytecode, an ABC bytecode parsing/publishing and bytecode based reflection API for ActionScript 3.0, formerly known as Loom. (http://code.google.com/p/loom-as3/).

It offers bytecode based reflection, giving a developer access to a much richer set of reflection information than that retrieved from the native describeType() method.
Check this link for more information about this feature: Bytecode reflection.

Secondly it offers the emit API, enabling a developer to define, generate and load Actionscript classes at runtime.
Check this link for more information about this feature: Runtime class generation.

And lastly, the library has just added support for runtime dynamic proxy generation in this v0.9 release. Dynamic proxies will bring the first, albeit limited, AOP possibilities to Actionscript.
Check this link for more information about this feature: Dynamic proxy generation.

For the upcoming release support for proxying protected and custom namespace scoped members for dynamic proxies is planned. Along with bytecode weaving AOP support.

Until then, try out the library and report any bugs or ideas here: Issues.

Cheers,

Roland

Spring Actionscript 1.0 released!

2010-09-13T04:54:00.000-07:00

As usual Herrodius.com has the complete lowdown:

http://www.herrodius.com/blog/350

Or you can head over to the changelog immediately:

http://www.springactionscript.org/changes-report.html#a1.0

if you have any questions or criticism, please visit the forums:

http://forum.springsource.org/forumdisplay.php?f=60

Cheers!

Released: Spring Actionscript version 1.0 Release Candidate 1 now available!

2010-03-01T12:01:00.000-08:00

Finally, Spring Actionscript 1.0 RC1 sees the light of day!

Get all the juicy details over at Herrodius' blog:

http://www.herrodius.com/blog/273

or just read the changelog here:

http://www.springactionscript.org/changes-report.html#a1.0RC1

if you have any questions or criticism, please visit the forums:

http://forum.springsource.org/forumdisplay.php?f=60

Cheers!

Spring Actionscript version 0.8.1 released!

2009-09-15T13:59:00.000-07:00

Its mainly a maintenance release with a slew of bugfixes, but there's some new functionality in there as well.
Read the full story at Herrodius' blog as per usual:

http://www.herrodius.com/blog/208

Download away:

http://www.springactionscript.org

Here's the changelog:

http://www.springactionscript.org/changes-report.html#a0.8.1

And should you find any bugs or have some feature request, please head on over to JIRA:

http://jira.springframework.org/browse/SESPRINGACTIONSCRIPTAS

cheers!

Spring Actionscript version 0.8 released!

2009-07-17T09:40:00.000-07:00

Get the full story at herrodius blog:

herrodius.com

read the new documentation site front to back:

springactionscript.org

For all people upgrading from an older version and haven't done so, make sure you change the namespace declarations in your configuration files! Failing to do so will prevent springactionscript from working properly. (well, it won't work at all actually :))
This is what your XML should look like:

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

</objects>

That's the most important part to check.

Here's a quick glance at the changelog:

Changes in version 0.8 (16.07.2009)
-----------------------------------

General
* new website at www.springactionscript.org
* factored out common functionality into the AS3Commons projects (http://www.as3commons.org)
* major update to the documentation
* added autowire support
* added custom namespace handler support
* restructured subversion repository
* updated samples
* various performance improvements

Package org.springextensions.actionscript.cairngorm
* added IDataTranslator and IDataTranslatorAware interfaces
* added AbstractDataTranslatorAwareBusinessDelegate base class
* added 'batch command' support to CairngormFrontController

Package org.springextensions.actionscript.context.support.mxml
* added entire package for MXML support for application contexts

Package org.springextensions.actionscript.domain
* moved Enum to AS3Commons-Lang
* moved ICloneable to AS3Commons-Lang
* moved IEquals to AS3Commons-Lang

Package org.springextensions.actionscript.errors
* moved IllegalArgumentError to AS3Commons-Lang
* moved IllegalStateError to AS3Commons-Lang
* removed RuntimeError

Package org.springextensions.actionscript.ioc
* added "factoryObjectName" property to IObjectDefinition and ObjectDefinition

Package org.springextensions.actionscript.ioc.factory
* added ObjectDefinitionStoreError

Package org.springextensions.actionscript.ioc.factory.config
* added StageComponentInterceptionPostProcessor
* fixed e4x query to select nodes with Required metadata in RequiredMetadataObjectPostProcessor
* changed "getObject" and "getObjectType" so we can also return Function references from methods in FieldRetrievingFactoryObject
* added "getObjectDefinition" in IConfigurableListableObjectFactory

Package org.springextensions.actionscript.ioc.factory.config.flex
* added ApplicationPropertiesResolver

Package org.springextensions.actionscript.ioc.factory.support
* removed "allowObjectDefinitionOverriding" getter and setter from IObjectDefinitionRegistry
* error is now thrown when overriding an object definition while it is not allowed in DefaultListableObjectFactory
* added support for retrieving factory objects and autowiring in AbstractObjectFactory
* added ObjectDefinitionBuilder
* fixed bug with caching of factory objects in AbstractObjectFactory

Package org.springextensions.actionscript.ioc.factory.xml
* added StageInterceptionNamespaceHandler
* added spring-actionscript-stageinterception-1.0.xsd
* added spring_actionscript_stageinterception namespace
* added RPCNamespaceHandler
* added spring-actionscript-rpc-1.0.xsd
* added spring_actionscript_rpc namespace
* added UtilNamespaceHandler
* added spring-actionscript-util-1.0.xsd
* added spring_actionscript_util namespace
* added MessagingNamespaceHandler
* added spring-actionscript-messaging-1.0.xsd
* added spring_actionscript_messaging namespace
* added "resolveID" to AbstractObjectDefinitionParser method that allow object name lookup and generation

Package org.springextensions.actionscript.ioc.factory.xml.parser.support
* fixed XMLObjectDefinitionsParser so that abstract definitions are no longer parsed
* fixed XMLObjectDefinitionsParser to support nested custom nodes

Package org.springextensions.actionscript.ioc.factory.xml.parser.support.nodeparsers
* fixed ObjectNodeParser to support nested custom nodes

Package org.springextensions.actionscript.ioc.factory.xml.parser.support.nodeparsers.stageinterception
* added StageInterceptorNodeParser

Package org.springextensions.actionscript.ioc.factory.xml.preprocessors
* fixed parent properties not being overridden by child properties in ParentAttributePreprocessor
* fixed bug with properties replacement

Package org.springextensions.actionscript.mvcs
* removed AbstractService
* added IApplicationController
* added AbstractApplicationController
* added ApplicationEvent
* added ApplicationEventDispatcher
* added IApplicationEventListener

Package org.springextensions.actionscript.utils
* added ApplicationUtils
* moved ArrayUtils to AS3Commons-Lang
* moved Assert to AS3Commons-Lang
* moved DictionaryUtils to AS3Commons-Lang
* moved ObjectUtils to AS3Commons-Lang
* moved StringUtils to AS3Commons-Lang
* moved XMLUtils to AS3Commons-Lang
* removed TypedProxy

Samples
* added object-definition-parser-builder project

Go get it while its hot!

as3commons v1.0 released

2009-05-31T09:17:00.000-07:00

Just a quicky, as3commons version 1.0 has just been released, check it out here:

http://www.as3commons.org/

AS3Commons contains so far:

Reflect:
AS3Commons-reflect is an open-source library providing a reflection API for ActionScript 3.0. Being a pure actionscript library it can be used for any Flash/Flex/AIR project.

Logging:
AS3Commons-logging is an open-source library providing an abstraction over logging framework implementations. Being a pure actionscript library it can be used for any Flash/Flex/AIR project. Its use is recommended for use with other libraries/framework trying to be logging framework agnostic.

Go and check it out!

Spring Actionscript + Cairngorm + Convention based coding == Less configuration

2009-04-30T03:30:00.000-07:00

Spring Actionscript and its Cairngorm extensions provides you with a really nice way of configuring your events, command and delegates. Coupled with its AbstractCommandFactory it also makes your life very easy when it comes to injecting your commands and delegates with all sorts of properties.
It does, however, lead to quite a lot of configuration markup which, in turn, means a lot of typing for you, the developer.

Let's see if we can cut down on the amount of markup by using a little bit of convention based coding, a post processor and the new auto wiring functionality in Spring Actionscript.

Mind you, the new autowiring capabilities will be implemented in version 0.8 of Spring Actionscript, which isn't officialy released yet. So, to use these new features, you'll have to get the source form the SVN repository directly and compile your own version.
In my examples I also use the AS3Commons-Reflect library for a bit of reflection, you can find the lib here:
AS3-Reflect

Let's first define the naming convention for events, commands and delegates, in my example I use this:

<namespace>.events.<identifier>Event
<namespace>.commands.<identifier>Command
<namespace>.delegates.<identifier>Delegate

If I'm going to use the example of a GetProducts gesture the naming of the classes would then be, for example:

com.classes.cairngorm.events.GetProductsEvent
com.classes.cairngorm.commands.GetProductsCommand
com.classes.cairngorm.delegates.GetProductsDelegate

Let's start coding immediately.
The event class would be very straight-forward:

public class GetProductsEvent extends CairngormEvent
{
public static const EVENT_ID:String = "com.classes.cairngorm.events.GetProductsEvent";

public function GetProductsEvent()
{
super(EVENT_ID);
}

}

Do notice that I use the fully qualified classname of the event class as its ID though, this will be used later on when we associate the event with its corresponding command.

Normally we would configure our frontcontroller in the Spring Actionscript markup like this:

<object id="frontController" class="org.springextensions.actionscript.cairngorm.control.CairngormFrontController" singleton="true">
<constructor-arg>
<object>
<property name="com.classes.cairngorm.events.GetProductsEvent"
value="com.classes.cairngorm.commands.GetProductsCommand"/>
</constructor-arg>
</object>

But not this time, we only create an 'empty' frontcontroller, like so:

<object id="frontController" class="org.springextensions.actionscript.cairngorm.control.CairngormFrontController"/>

Instead, we create an IObjectPostProcessor implementation that creates the event/command object mapping for us, based on our naming convention.
Any IObjectPostProcessor that is declared in the Spring Actionscript configuration will automatically be called for every object that is instantiated by the Spring AS container. So also for our FrontController. Here's how such an IObjectPostProcessor can be used to configure your frontcontroller automatically:

public class FrontControllerPostprocessor extends Object implements IObjectPostProcessor
{
public function FrontControllerPostprocessor()
{
super();
}

private var _eventIds:Array;
//this is an array of event id strings:
public function set eventIds(value:Array):void
{
_eventIds = value;
}

//we won't do anything before the command is initialized, so just return null here
public function postProcessBeforeInitialization(object:*, objectName:String):*
{
return null;
}

//After the object has been initialised, check if the current object is an instance
//of CairngormFrontController. If so, perform the configuration:
public function postProcessAfterInitialization(object:*, objectName:String):*
{
var frontController:CairngormFrontController = (object as CairngormFrontController);
if (frontController != null)
{
frontController.commandMap = createCommandMap();
}
}

//Loop through the event id list and generate a valid command class based on each ID:
private function createCommandMap():Object
{
var commandMap:Object = {};
if (_eventIds != null)
{
_eventIds.forEach(function(item:String,index:int,arr:Array):void
{
commandMap[item] = createCommandClass(item);
});
}
return commandMap;
}

//Generate a class name for the specified eventId
private function createCommandClass(eventId:String):String
{
//The event id is the same as its fully qualified classname, like this:
//com.classes.cairngorm.events.GetProductsEvent
//therefore we split the path on its period character:
var parts:Array = eventId.split('.');
//the last element of the resulting array will be the eventname, this we
//want to keep for now:
var eventName:String = String(parts.pop());
//the next element is the 'events' part, let's get rid of this:
parts.pop();
//finally, we join back to the first part of the path, add the 'commands'
//part and replace the 'Event' part of the eventid with 'Command'
// and we end up with a valid command class:
//com.classes.cairngorm.commands.GetProductsCommand
return parts.join('.') + '.commands.' + eventName.replace('Event','Command');
}
}

That takes care of our frontcontroller, it now knows which command to create for which event, wonderful!

Now, our command will need a reference to the application model (because I'm pretty sure we will want the result of our GetProducts call to end up in the model, right?), for this we will make an interface called IModelLocatorAware. Its signature is very simple:

public interface IModelLocatorAware
{
function set modelInstance(value:IModelLocator):void;
}

And thusly, our GetProductsCommand's implementation will look like this:

public class GetProductsCommand extends AbstractResponderCommand implements IModelLocatorAware
{
public function GetProductsCommand()
{
super();
}

override public function execute(event:CairngormEvent):void
{
//extra logic goes here...
GetProductsDelegate(businessDelegate).getProducts();
}

private var _modelInstance:IModelLocator;
public function set modelInstance(value:IModelLocator):void
{
_modelInstance = value;
}

override public function result(data:Object):void
{
var resultEvent:ResultEvent = data as ResultEvent;
//extra logic goes here...
}

override public function fault(info:Object):void
{
var faultEvent:FaultEvent = info as FaultEvent;
//extra logic goes here...
}

}

As you see, in the execute method, this command expects its businessDelegate instance to be of type GetProductsDelegate.
We want to make sure that such a delegate has been injected into our command instance.
For this we will create a command factory. Spring Actionscript's CairngormFrontController allows us to add ICommandFactory instances that take care of the creation of certain classes of commands.
What we want is a factory that not only creates the right command, but also injects it with a reference to the application model and the right business delegate instance.
It doesn't take that much code, check out this command factory:

public class AutowiringCommandFactory implements ICommandFactory, IApplicationContextAware
{
public function AutowiringCommandFactory()
{
super();
}

//this factory implements the IApplicationContextAware interface, which means it
//will automatically be injected with the IApplicationContext instance that
//created it. We will use the IApplicationContext to perform the autowiring.
private var _applicationContext:IApplicationContext;
public function set applicationContext(value:IApplicationContext):void
{
_applicationContext = value;
}

//In this example we will be arrogant and claim we are able to create any
//command possible:
public function canCreate(clazz:Class):Boolean
{
return true;
}

//And here we actually create the reuqested class and inject it with the
//appropriate instances
public function createCommand(clazz:Class):ICommand
{
//First we retrieve the fully qualified classname and create an
//IObjectDefinition instance based on this classname. We then
//set the autowiring mode to 'byName' and let the IApplicationContext
//inject any properties that are defined in the container by name.
//(in our case the ModelLocator instance)
var className:String = Type.forClass(clazz).fullName;
var objectDefinition:IObjectDefinition = new ObjectDefinition(className);
objectDefinition.isSingleton = false;
objectDefinition.autoWireMode = ObjectDefinitionAutowire.AUTOWIRE_BYNAME;
var command:AbstractResponderCommand = new clazz() as AbstractResponderCommand;
_applicationContext.wire(command,objectDefinition);
//Then we create a business delegate based on the naming convention of our command classname:
var delegate:IBusinessDelegate = createBusinessDelegate(className);
delegate.responder = command;
command.businessDelegate = delegate;
return command;
}

//Assemble the business delegate class name, much in thew same way as we assembled the
//command class name based on the event ID:
private function createBusinessDelegate(commandClassName:String):IBusinessDelegate
{
var parts:Array = commandClassName.replace('::','.').split('.');
var delegateName:String = String(parts.pop());
parts.pop();
var businessDelegateName:String = parts.join('.') + '.delegates.' + delegateName.replace('Command','Delegate');
var cls:Class = (getDefinitionByName(businessDelegateName) as Class);
//com.classes.cairngorm.delegates.GetProductsDelegate
return new cls() as IBusinessDelegate;
}
}

So, now all we really need is the final Spring Actionscript configuration to tie this all together:

<?xml version="1.0" encoding="utf-8"?>
<objects>

<object id="modelInstance" class="com.classes.cairngorm.model.ModelLocator" singleton="true"/>


<object id="frontController" class="org.springextensions.actionscript.cairngorm.control.CairngormFrontController">
<method-invocation name="addCommandFactory">
<arg>
<object class="com.classes.cairngorm.commands.factory.AutowiringCommandFactory"/>
</arg>
</method-invocation>
</object>


<object id="frontControllerPostProcessor" class="com.classes.spring.postprocessors.FrontControllerPostprocessor">
<property name="eventIds">
<value>
<array>
<value>com.classes.cairngorm.events.GetProductsEvent</value>
</array>
</value>
</property>
</object>
</objects>

And that's it! With only the power of autowiring, post processing and a little bit of 'convention over configuration' we slimmed down our configuration markup considerably!

Of course, its debatable whether such an approach would be recommended in a large application with many, many events and commands. It does save a bunch of time typing out the markup but may make your overal source a little harder to understand for newcomers to the project.
This is a matter of preference I suppose, there's a case for and against it, I believe with proper project documentation this would be a viable solution. But it certainly isn't appropriate for every occasion, I admit.

I hope however, that this post does shine a little bit of light on the new autowiring capabilities of Spring Actionscript and may introduce some people to the wonderful world of the IObjectPostprocessor :)

Whitespace frustrations

2009-02-05T04:20:00.000-08:00

Update:
So, I got it to work eventually. Apparently if I also set this property:
XML.prettyPrinting = false;
I get the expected results. Not pretty at all, but at least it solved my problem for now...

I'm making this little Flex proof-of-technique application currently that deals with quite a bit of XML.
One of the first things I encountered was that an element looking like this:

<node>text with trailing whitespace </node>

The text of this node ended up in my object as 'text with trailing whitespace'. So *without* the trailing space, which was essential to DO end up there.

Well, a quick google turned out that before I parse my incoming XML I should add this line of code:

XML.ignoreWhitespace = false;

And then create my XML object.

On a side note, I think its kind of weird to set such a parameter through a static property. In my opinion it would have made more sense to just add a constructor argument which defaults to true, sort of like this:

var ignorewhitespace:Boolean = false;
var xmlObject:XML = new XML(BigFrakkingXMLString,ignorewhitespace);

But, unfortunately my problems weren't over.
On my way back to the server I'm supposed to create an XML object and send this.
So, what do I do? I set the static property: XML.ignoreWhitespace = false;
And I start creating elements and adding them to my XML object.
For example, I add an element like this:

var contentXML:XML = new XML("<Content>" + someStringOfText + "</Content>");

where the someStringOfText string has a value of, for example, "some text with a trailing space again ".

Yet, somehow the element ends up looking like this:

<Content>some text with a trailing space again</Content>

So, am I dealing with a bug here, or am I doing something fundamentally wrong here again?

I guess an option would be to just send value objects back to the server and handle all of the XML creation there. But I'm sort of buggered by the fact that I seem to hit a wall here over such a small little issue...

Different ways of forcing Flex to compile a class

2009-01-23T00:32:00.001-08:00

As a user of Spring Actionscript I have, of course, run into the problem of classes not being compiled into the swf file.

When you have defined an object in the Spring AS configuration, but there's not direct reference in your source code to the class, the Flex compiler will optimize the class out of the swf and you end up with runtime errors such as this:


a class with the name 'x.y.z' could not be found

So far I know of three different ways to tackle this problem:

1. Add dummy variables in your source code like this:


privare var _dummy1:MyClass;
privare var _dummy2:MyOtherClass;

2. Add a Frame tag for each class you want to be included to one dummy class, and include only that dummy class. Code would look like this:


package com.myclasses
{
   [Frame(extraClass="com.myclasses.MyClass")]
   [Frame(extraClass="com.myclasses.MyOtherClass")]
   public class MyDummyClass
   {
   }
}

3. Use a bit of XSLT, an ANT script and add this a builder in FlexBuilder. I have posted a PDF with a how-to on the springsource forums over here:

Spring Actionscript forum post

Hopefully in the future there will be a more elegant way of forcing certain classes to be included, but until then, pick one of these solutions.

Introducing: As3UndoHistory

2009-01-14T12:53:00.000-08:00

Ok, so I've released a first version of my little undohistory lib on google code,
go and get it here:
as3undohistory

You can pull the sources right from the SVN repository there. So far I haven't made a release package because the whole thing's fairly small anyways.

There's three projects in the repository, the actual library, a unit test project and an example application which showcases what the library actually does.

I have no idea how well the library scales, I guess registering a few thousand objects with each 50 properties and then changing each property say 200 times will eventually eat a bunch of memory. It might be worth a stress test at some point. But on the other hand, I wouldn't know how to record changes in a different way than this. But then again, I'm just a bonehead, so if anyone has a better approach to this kind of edit history recording, I'd love to hear it.

I'll be working on the documentation some more this evening I guess because, right now, its almost non-existent. Should anybody be interested in using the library, go ahead and please give me a yell should you find any bugs.

Cheers.

undo history management in Flex

2009-01-13T02:41:00.000-08:00

So I have a major flu which puts me in bed bored out of my skull...
I have this ongoing project, a Flex application, which is basically a sort of mind mapping system crossed with a drawing application. Now one of the next feature requests that the client made is an undo history.

Yikez.

So, I've been toying around with how to do it, and came up with, what I think, is a workable solution. I don't follow the usual command pattern which you find in most google searches on flex + undo history. What I basically needed was a recording of all the property changes on a bunch of objects.
I.e. property color was set to #00000, property width was set to 150, etc, etc.
These changes have to be recorded chronologically and undoing would basically be a matter of popping entries off a stack.

So, my solution makes use of some metadata and requires the objects that will be monitored to implement their properties with getters and setters.
An undoable property would look something like this:


[Undoable]
public function get testStringProperty():String
{
   return _testStringProperty;
}
[Bindable(event="testStringPropertyChanged")]
public function set testStringProperty(value:String):void
{
   if (value != _testStringProperty)
   {
       _testStringProperty = value;
       dispatchEvent(new Event("testStringPropertyChanged"));
   }
}

The object that implements this property needs to be registered once with a history manager class which analyzes the metadata and sets up eventlisteners,etc. In my implementation I use Christophe Herremans as3reflect library for retrieving the metadata.

My undo history manager also supports simple transactions, in the case several property changes represent only one user gesture. This is simply a matter of calling startTransaction and endTransaction on the history manager.

Anyways, I'm still busy cleaning up the code, finishing the documentation and making a little example application. But when I'm finished I'll release this on google code so maybe somebody else can benefit from this as well.

Or maybe someone on the interwebs thinks my solution is absolutely ridiculous, then I'd like to hear about it too :)

For now, I'm going back to being sick with the flu.

Cheers.