Spring ActionScript at FlexCamp 2008 Belgium

ActionScript, Conferences, Flex, Inversion of Control, Spring ActionScript, Talks Add comments

Here's a rundown of the presentation I did on Spring ActionScript at the FlexCamp in Antwerp, Belgium. In 40 minutes I tried to cover the basic theory on Inversion of Control, Dependency Injection and the Spring ActionScript project in general. We then dove right into some code we've been writing for an enterprise app that extensively uses Spring ActionScript's IoC container.

Spring ActionScript
View SlideShare presentation or Upload your own. (tags: flash air)

Since time was limited (or in case you were not there), I'll run through the key features of the code I ran through and try to give some more explanation.

Targeting BlazeDS via remoting and messaging

Whenever I'm hitting a backend, I try to have the endpoints externally configured. This allows me to switch between different endpoints - different test or production servers for instance - just by specifying the ip and port in an external properties file. This means that you don't have to specify any compiler arguments that point to the services-config.xml or messaging-config.xml files.

You can set up a channelset and a consumer with the following code. Notice the "method-invocation" element that allows you to execute a method on the object you create. This allows us to directly pass in a channel to the channelset. (In case you are interested, the method-invocation element is preprocessed to an instance of MethodInvokingFactoryObject)

CODE:
  1. <object id="channelSet" class="mx.messaging.ChannelSet">
  2.     <method-invocation name="addChannel">
  3.         <arg>
  4.             <object id="streamingAMFChannel" class="mx.messaging.channels.StreamingAMFChannel">
  5.                 <property name="url" value="http://${host}:${port}/${context-root}/messagebroker/streamingamf" />
  6.             </object>
  7.         </arg>
  8.     </method-invocation>
  9. </object>
  10.  
  11. <object id="eventMessageFeedConsumer" class="mx.messaging.Consumer">
  12.     <property name="destination" value="eventMessageFeed" />
  13.     <property name="channelSet" ref="channelSet" />
  14. </object>

Have you noticed the placeholders "${...}" for the host, port and context-root? These are loaded from a properties file that is referenced in the application context file.

Here's the external properties file:

CODE:
  1. host=192.168.2.134
  2. port=8081
  3. context-root=server-web

And here's the import declaration in the application context xml file:

CODE:
  1. <property file="application-context.properties.txt" />

Of course, you can also specify remote objects in the application context. Here's an example:

CODE:
  1. <object id="remoteObject" class="mx.rpc.remoting.mxml.RemoteObject" abstract="true">
  2.     <property name="endpoint" value="http://${host}:${port}/${context-root}/messagebroker/amf" />
  3.     <property name="showBusyCursor" value="true" />
  4. </object>
  5.  
  6. <object id="userRemoteObject" parent="remoteObject">
  7.     <property name="destination" value="userService" />
  8. </object>

Notice that we actually split this up into 2 objects. The first object is an abstract remote object which we use as a parent object for concrete remote objects. Notice the "abstract=true" and the "parent=remoteObject" properties on these objects.

MVCS support

As part of the project we are working on, we also starting working on some experimental MVCS support. If you haven't heard of MVCS, be sure to check out at Joe Berkovitz' blog.

What we provide so far are some interfaces and abstract base classes for services, operations and commands. Let's look at some code for services and operations.

Here's an interface for a user service, which defines a "getAll" method.

CODE:
  1. public interface IUserService {
  2.   function getAll():IAsyncOperation;
  3. }

We now want to create a concrete service for that interface. For instance, this could be a remote object enabled service. For that, we have a abstract remote object service base class.

CODE:
  1. public class UserRemoteObjectService extends AbstractRemoteObjectService implements IUserService {
  2.        
  3.     public function UserRemoteObjectService(remoteObject:RemoteObject) {
  4.         super(remoteObject);
  5.     }
  6.  
  7.     public function getAll():IAsyncOperation {
  8.         var token:AsyncToken = remoteObject.getAll();
  9.         token.addResponder(new Responder(onGetAllResult, onGetAllFault));
  10.         return getOperation("getAll");
  11.     }
  12.        
  13.     private function onGetAllResult(event:ResultEvent):void {
  14.         getOperation("getAll").dispatchEvent(new AsyncOperationResultEvent(event.result));
  15.     }
  16.        
  17.     private function onGetAllFault(event:FaultEvent):void {
  18.         getOperation("getAll").dispatchEvent(new AsyncOperationErrorEvent(event.fault.faultDetail));
  19.     }
  20. }

For testing purposes, we could also create a mock user service:

CODE:
  1. public class UserMockService extends AbstractService implements IUserService {
  2.    
  3.     private static var logger:ILogger = Log.getLogger("UserMockService");
  4.    
  5.     public function UserMockService() {
  6.         logger.warn("Mock user service instantiated.");
  7.     }
  8.        
  9.     public function getAll():IAsyncOperation {
  10.         var users:ArrayCollection = new ArrayCollection();
  11.        
  12.         var user1:User= new User();
  13.         user1.name = "John";
  14.         users.addItem(user1);
  15.            
  16.         var user2:User= new User();
  17.         user2.name = "Peter";
  18.         users.addItem(user2);
  19.            
  20.         setTimeout(onGetUsersResult, Math.random()*3000, users);
  21.           CursorManager.setBusyCursor();
  22.            
  23.         return getOperation("getAll");
  24.     }
  25.        
  26.     private function onGetUsersResult(users:ArrayCollection):void {
  27.         var operation:IAsyncOperation = getOperation("getAll");
  28.         operation.dispatchEvent(new AsyncOperationResultEvent(users));
  29.         CursorManager.removeBusyCursor();
  30.     }
  31. }

We can now define these objects in the application context as follows:

CODE:
  1. <object id="userService" class="UserMockService"/>
  2.  
  3. ... or ...
  4.  
  5. <object id="userService" class="UserRemoteObjectService">
  6.     <constructor-arg>
  7.         <object id="userRemoteObject" parent="remoteObject">
  8.             <property name="destination" value="detectorGroupService" />
  9.         </object>
  10.     </constructor-arg>
  11. </object>

You can now use one of these implementations by calling the getAll() method. Make sure that you type the service to IUserService and not to a concrete implementation:

CODE:
  1. public function getUsers():void {
  2.     var operation:IAsyncOperation = _userService.getAll();
  3.     operation.addEventListener(AsyncOperationEvent.RESULT,
  4.         function(e:AsyncOperationResultEvent):void {
  5.             logger.info("Users loaded successfully.");
  6.             var users:ArrayCollection = ArrayCollection(e.result);
  7.         }
  8.     );
  9.     operation.addEventListener(AsyncOperationEvent.ERROR,
  10.         function(e:AsyncOperationErrorEvent):void {
  11.             logger.error("An error occurred when loading the users: " + e.fault);
  12.         }
  13.     );
  14. }

To implement your own services, you don't necessarely need to extend the AbstractService or AbstractRemoteObjectService class. These base classes just provide you with some convenient methods, like "getOperation" that creates a generic AsyncOperation for you.

You could of course also create an own implementation of the IAsyncOperation interface for your specific needs. For instance, you could create a GetAllUsersOperation that has all the logic for invoking a method on a remote object and that also deals with the result and fault handling of the remote call.

Presentation Model and Autowiring

I mentioned that we were using Presentation Model to seperate our UI state and logic from our views. This has worked surprisingly well for us and it certainly allows us to write better tests (for the presentation model). If you are new to Presentation Model and Presentation Patterns in general, I really recommend taking a look at the writings by Martin Fowler and Paul Williams.

Seperating logic and state from the view is one thing, but of course in order to use this combination you have to provide your view with an instance of a presentation model at some point. It's easy to read a presentation model from an application context, but injecting it is not that easy. Especially if your view component is nested a few levels deep inside other view components, it can be tricky to pass in the instance of the presentation model. We started of by passing in the presentation models from the root of the application through all components until we had finally reached the component that needed the presentation model. Needless to say that this approach required us to write a lot of extra code that really wasn't supposed to exist...

Enter custom metadata and SystemManager! Using the systemManager, you can listen to events that get fired when view components are added to the stage. This was exactly what we needed to know. Combined with a custom metadata element [Autowired], we now support dependencies being injected into views automatically.

Here's how it works. Suppose you have a UserPanel and a UserPanelPresentationModel. In you UserPanel you'll have a reference to that presentation model so you can actually use it in your view component. By adding the extra [Autowired] metadata you can mark a property (the presentation model) as a property that needs to be autowired when the view is created and added to the stage.

In your UserPanel.mxml file, you declare the presentation model as follows.

CODE:
  1. [Bindable]
  2. [Autowired]
  3. public var presentationModel:UserPanelPresentationModel;

Now all we need to do is listen to the ADDED event on the systemManager and write some glue code that injects the presentation models defined in the application context into the view components. This code goes in your main application file.

CODE:
  1. import mx.utils.DescribeTypeCache;
  2. import mx.utils.DescribeTypeCacheRecord;
  3.  
  4. ...
  5.  
  6. systemManager.addEventListener(Event.ADDED, onAdded);
  7.  
  8. ...
  9.  
  10. private function onAdded(event:Event):void {
  11.   var autowiredObject:Object = event.target;
  12.   var typeInfo:DescribeTypeCacheRecord = DescribeTypeCache.describeType(autowiredObject);
  13.  
  14.   for each (var metaDataNode:XML in typeInfo.typeDescription..metadata) {
  15.     if (metaDataNode.attribute("name") == "Autowired") {
  16.       var propertyNode:XML = metaDataNode.parent();
  17.       var property:String = propertyNode.@name.toString();
  18.       var objectName:String = property;
  19.       var autowireByType:Boolean = true;
  20.  
  21.       for each (var arg:XML in metaDataNode.arg) {
  22.         if (arg.attribute("value") == "byName") {
  23.           autowireByType = false;
  24.         }
  25.       }
  26.                        
  27.       if (autowireByType) {
  28.         var clazz:Class = ClassUtils.forName(propertyNode.@type.toString());
  29.         var objectNames:Array = m_applicationContext.getObjectNamesForType(clazz);
  30.         if (objectNames.length == 1) {
  31.           objectName = objectNames[0];
  32.         }
  33.       }
  34.                        
  35.       autowiredObject[property] = m_applicationContext.getObject(objectName);
  36.     }
  37.   }
  38. }

You may have noticed that we do some extra checks on the attributes of the Autowired metadata. This is because the code above support autowiring by type (the default) and autowiring by name. Autowiring by type means that we will look in the context for objects that are of a certain type. If we find one, we will inject it. Autowiring by name means that we will look for objects in the context that have a certain id.

You can set up autowiring by name as follows:

CODE:
  1. [Bindable]
  2. [Autowired(mode="byName")]
  3. public var presentationModel:UserPanelPresentationModel;

Conclusion

I hope you now got a good understanding of some of the key features, best practices and what we are doing with Spring ActionScript in general. Don't hesitate to join our forum or the team if you want to help us out. We are really looking for more people to join, especially for working on samples and documentation.

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


Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 

7 Responses to “Spring ActionScript at FlexCamp 2008 Belgium”

  1. Lieven Cardoen Infrarood Says:

    Hi Herrodius, hopefully some people understood some things you said ;-) !

    Keep it up!

    Grab a bite somewhere next week?

  2. magomarcelo Says:

    I’m trying to use autowiring but with the latest Spring ActionScript 0.7.1 and the version of as3reflect included I get an array when I call accessor.getMetaData(“Autowired”) instead of a single MetaData object

  3. Christophe Herreman Says:

    Yes, I should have updated the code since that method has changed a bit since this post was published.

    Here is a newer version of the autowiring code. It does not use AS3Reflect for performance reasons.

    You’ll manually need to import the following:
    import mx.utils.DescribeTypeCache;
    import mx.utils.DescribeTypeCacheRecord;

    (I’ll also update the code)

    ***

    private function onAdded(event:Event):void {
    var autowiredObject:Object = event.target;
    var typeInfo:DescribeTypeCacheRecord = DescribeTypeCache.describeType(autowiredObject);

    for each (var metaDataNode:XML in typeInfo.typeDescription..metadata) {
    if (metaDataNode.attribute(“name”) == “Autowired”) {
    var propertyNode:XML = metaDataNode.parent();
    var property:String = propertyNode.@name.toString();
    var objectName:String = property;
    var autowireByType:Boolean = true;

    for each (var arg:XML in metaDataNode.arg) {
    if (arg.attribute(“value”) == “byName”) {
    autowireByType = false;
    }
    }

    if (autowireByType) {
    var clazz:Class = ClassUtils.forName(propertyNode.@type.toString());
    var objectNames:Array = m_applicationContext.getObjectNamesForType(clazz);
    if (objectNames.length == 1) {
    objectName = objectNames[0];
    }
    }

    autowiredObject[property] = m_applicationContext.getObject(objectName);
    }
    }
    }

  4. TK Says:

    [property file="something.properties"/]

    Wish it were that easy in Spring proper :) Good job Christophe! Way to go, team!
    And I love the “method-invocation” tag, by the way :)

  5. Gordon Says:

    This method is very appealing, however have you seen a noticeable performance impact? It seems like it could be expensive using as3 “reflection” (parsing an xml document) every time any UIComponent in the application is added as a child to something.

  6. Ruprict Says:

    So, I am trying to run this on a module after it’s loaded, but the [Autowired] metadata nodes don’t show up in the typeDescription. The Bindable metadata is all there, and the var I decorated is there, it just doesn’t have the Autowired metadata. Any ideas what I am messing up?

    Thanks,
    Ruprict

  7. Ruprict Says:

    Ugh…never mind. -keep-as3-metadata Autowired

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in