Second Generation Micro-architectures
One of the primary reasons we have microarchitectures and design patterns in the first place is to maximize simplicity in application code. The problem is that not every architect understands this. Often we find architectures and design patterns being used in ways that do nothing more than increase complexity, which is counter-intuitive. This is why it is important to understand the framework that you are working with before you begin development on a production project that uses it, and Swiz is no exception.
A common characteristic among second-generation micro-architectures is that they are built to empower the developer, rather than over-power. One thing that all of these second-generation microarchitectures have in common, is that they use some form of Inversion of Control (IoC) and Dependency Injection, as defined by the great Martin Fowler in his book Patterns of Enterprise Application Architecture (Addison Wesley, 2002). With that in mind, you will first learn a bit about how these design patterns work from a conceptual standpoint before you get your hands dirty.
A Quick Background on Inversion of Control & Dependency Injection
Generally speaking, a good microarchitecture should allow the developer to decide how to implement an effective model based on the unique characteristics of the application. As previously stated, it should never force the developer into a specific model implementation. The Flex Framework is largely based on principles of Inversion of Control (IoC). In fact, this is true for most event-driven user interface development toolkits and frameworks such as Java Spring, EJB 3, Spring.NET, the ColdSpring framework for Coldfusion, Needle for Ruby, and FLOW3 for PHP 5.
The Inversion of Control pattern originally comes from another pattern described in a very important book published in 1995 that is often referred to as the “gang of four” or “gof” book, titled Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley). If you do not have this book already, I strongly suggest you add it to your collection as it considered a staple by every good developer I have ever met. One of the 22 design patterns described in this book is the Factory Method Design Pattern. IoC is a derivative of this pattern.
Why does ActionScript works well with IoC?
As you have learned, the ActionScript language is an object-oriented language in which objects are instantiated by declaring new instances, like so:
private var thisObject:ThisObject = new ThisObject(params...);
In contrast, IoC instantiates and registers a specific set of pre-defined objects at runtime, and injects them into each other using a concept known as Dependency Injection. By injecting these dependencies at runtime, the dependencies can be quickly and easily modified because the objects remain loosely coupled. The objects are loosely coupled because their dependencies are not “hard-coded” into the classes. This makes managing large code bases much easier.
Objects and object properties can then be wired up through binding. That means that all of your views and components can have what they need before anything ever even shows up on the stage!
With other implementations like Java Spring, an application’s objects and implementations can be declared in an XML document. However, this particular method is not possible with Flex due to the order of operations that happen at application startup. More specifically, an application is not ready to parse an XML document until after it’s objects have already been instantiated.
Coding Flex Applications with Swiz
Swiz caters specifically to enterprise level Flex development by providing a solid architectural foundation derived from proven enterprise application development patterns. This includes:
- Minimizing dependencies to promote loose coupling
- Inverting the flow of control
- Dynamic mediation
Swiz meta data: Autowire
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 cycle. 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. This is written as follows:
[Autowire]
[Bindable]
public var mainViewPModel:MainViewPresentationModel;
In the example above, the MainViewPresentationModel class is injected at runtime by Swiz as a result of the Autowire tag being placed above it. It is also made bindable in this instance so it can be referenced from properties of MXML components. Let’s say you have a Boolean property in MainViewPresentationModel called calendarVisible. Then, let’s say that when the application enters a certain state, calendarVisible gets set to true. (Note that calendarVisible should also be bindable in this case). In the MXML view that has the presentation model autowired into it, you could now state the following:
<components:CustomCalendar id="calendar" visible="{mainViewPModel.calendarVisible}" />
Ok, so what’s so special about that? Well, now let’s say you have an event called mainStateChanged, which is mediated in the controller class (more on event mediating in a moment). When the event is fired, the controller that is mediating it picks it up during the bubbling phase, and initiates the setting of calendarVisible to true. Since we’re binding to that value in the visible property of the component, the calendar will immediately become visible! Ok, now that you’ve got that figured out, it’s time to learn about mediating events.
Using the Mediate Tag
The first and most important thing I should note in regard to using the Mediate tag, is that events should ONLY be mediated in controller classes. If you place Mediate tags all over the application, mediating events in the model and the view for example, your application will be seem just as much like spaghetti-code as it would if you used no framework at all. Remember that Swiz gives you much flexibility, but with that flexibility comes a responsibility to use best practices when writing your code.
If you are already familiar with the publish-subscribe design pattern, then understanding event mediation should come fairly easily. The following code demonstrates the use of the Mediate tag:
[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 above, Swiz will always be listening for the DataEvent.SHOW_DATATIP event during application runtime. When Swiz finds a Mediate tag, it binds the specified event to the method that appears on the next line. When the event is fired, Swiz automatically calls that method.
In order to declare events with the ClassName.CONSTANT syntax as it is in the example code, you must tell Swiz where your events are located using the eventPackages property of the SwizConfig object that you declared in your main application file. Otherwise, you will need to use the fully qualified path when specifying the event that should be mediated.
Possibly Related Posts:
Posted by Dan Orlando on March 14th, 2010 :: Filed under
Enterprise FlexTags ::
microarchitecture,
Swiz,
Swiz framework
