In the last entry on the Swiz framework architecture, we took a look into the use of the CentralDispatcher. More specifically, we looked at the middle section of the following architectural diagram that I designed to help Swiz make more sense for developers. In this entry, we will get into the upper portion of the diagram, the real meat of the framework – Autowire and Mediate.
Architectural Diagram of the Swiz Framework
In declarative languages such as ActionScript, an object is created by declaring it and assigning the instance of that object to a variable using the new keyword. This has proven to be problematic in larger applications because of it’s “top-down” approach to object instantiation, which results in “tight coupling” (dependencies between otherwise independent objects) among other things.
In contrast, the Inversion of Control pattern used by Swiz reverses this object instantiation process by creating and implementing objects at application runtime. This eliminates dependencies and increases loose coupling because the implementation is created dynamically, as you are about to see.
The Swiz framework solves this problem rather inventively, through the use of two primary facets: the Swiz BeanLoader object and custom meta data tags. The Autowire tag is used for component wiring, while the Mediate tag is used for dynamic mediation of events during the bubbling phase of the event life cycle. These meta data tags are added to the framework simply by adding the following to the compiler settings in the Flex project properties panel:
-keep-as3-metadata +=Autowire,Mediate
Promote Loose Coupling with Autowire
Placing the Autowire meta data above the property of an object tells Swiz that it should inject a specified property from another class into this property, as seen in Listing 1.
Code Listing 1. Using the Autowire meta data tag
[Autowire( bean="displayRoot", property="currentView", twoWay="true" )]
[Bindable]
public var currentView:String;
You may have noticed three additional properties that immediately follow the Autowire declaration: bean, property, and twoWay. A bean represents an object that has been declared within a Swiz BeanLoader object; which brings us to…
The Swiz BeanLoader Object
Swiz does a superb job of separating the view from business logic. The concept of Beans and BeanLoaders are well known in Java GUI development circles, but have never been used before in application development for the Flash Platform. The result is a noticeable improvement in code organization, as well as the realization of a simple and clearly defined application life cycle.
A Swiz BeanLoader is an MXML file that acts similar to an object registry. When you create a bean loader, you’re extending the Swiz BeanLoader class, which registers the objects that you want Swiz to manage, as seen in Code Listing 2.
Code Listing 2. Example of a Swiz BeanLoader
<?xml version="1.0" encoding="utf-8"?>
<BeanLoader xmlns="org.swizframework.util.*" xmlns:view="com.danorlando.view.*">
<view:DisplayRoot id="displayRoot"/>
<view:StatsView id="statsView"/>
<view:VideoView id="videoView"/>
</BeanLoader>
The property value that is declared after the Autowire meta data pertains to the currentView variable in the displayRoot bean. Since the currentView property in code listing 1 and the respective currentView property that is found in the displayRoot bean are both marked accordingly, Swiz will create a binding between them to ensure that changes that occur to currentView in DisplayRoot are also propogated to the currentView property found in the component that holds the code found in listing 1 above. If that seemed like a lot to swallow, go through it a few times, this time taking it in bite-size chunks. This is one of the most important parts of Swiz, and has allowed me to do things with Flex and ActionScript that would otherwise be impossible.
The last property that is available with the Autowire meta data, called twoWay, is capable of setting up a reverse propagation in the other direction when set to true. In other words, the currentView property in the displayRoot bean will be updated if the currentView property in the component changes.
Save Time and Eliminate Repetitive Code with Dynamic Mediation
If you are already familiar with what a publish-subscribe design pattern is, then understanding dynamic mediation should be a piece of cake. To initialize dynamic mediation, the second Swiz meta data is used, called Mediate. Code listing 3 demonstrates the use of the Mediate meta data key word.
Listing 3. Using dynamic mediation in Swiz with the Mediate meta data key word
[Mediate( event="DataEvent.SHOW_DATATIP", properties="index,data" )]
public function showDataTip( index:int, data:ArrayCollection ):void {
var itemData:String = data.getItemAtIndex(index).toString;
var dataTip:DataTip = new DataTip(itemData);
addChild(dataTip);
}
In the example demonstrated in listing 3, Swiz is always listening for the DataEvent.SHOW_DATATIP event. This happens by binding the event to the method with Mediate. When the event is fired, Swiz automatically runs the method. It is noteworthy to point out however, that in order to declare the event class and type as shown in code listing 3, the respective package containing the event must be registered in the eventPackages configuration setting where <SwizConfig /> is declared in the main application file.
The greatest benefit of dynamic mediation is essentially the same as that which is gained from dependency injection and Autowire meta data. Objects do not have to have any knowledge about each other or the application for which they reside. Not only does this make unit testing ridiculously easy for the application, it takes the concept of “code reuse” to a whole new level.
To see the implementation of Swiz into an actual application, check out Ben Clinkinbeard’s post HERE.
Possibly Related Posts:
Posted by Dan Orlando on August 24th, 2009 :: Filed under
GeneralTags ::
Enterprise Flex,
Swiz,
Swiz framework
