I’ve spent an incredible amount of time recently working with the new Swiz framework for my latest article, which will be published soon by Linux Magazine.  Since Swiz is so new, and in consideration of the fact that very few developers even know what it is, the article was more of an “introduction to Swiz” type of article. However, as a result of the immense amount of time that I’ve spent analyzing the code and speaking with the developers, Chris Scott and Soenke Rohde, I decided to provide a more advanced architectural analysis of the framework here. If you are new to Swiz, my suggestion is to first read the introductory materials that are provided, or this article might make your head spin. I do not expect Linux to publish the article I wrote for them for at least another week, so if you need a basic introduction to the Swiz framework, I suggest taking a look at the project’s wiki on Google Code. For an excellent tutorial on creating a project with the Swiz framework, I strongly suggest taking a look at this five-part series written by Brian Koteck.

Swiz Architecture

I wanted to create a diagram to support the content of the article I was writing for Linux Magazine. However, what I ended up with was much more complex than I had intended. As a result, I created a simplified diagram for the article as a way of visualizing the application life cycle, and decided to post my original diagram here, which provides a visual depiction of both the behavior of Swiz, as well as its architecture. The diagram is shown in Figure 1. Note that you may click on the image to bring up a much larger version in another window. Viewing it that way may make it easier to comprehend as your read the following description.

Go with the Flow

The main application file is identified by the purple shape in the diagram with the text “Default Application”. In most Flex applications, this is usually an MXML file that extends Application or WindowedApplication. Note that projects that are purely ActionScript will not be able to take complete advantage of the features of the Flex framework. You will see why in just a bit. Swiz is fired up on the preinitialize event during application initialization, which initiates what I refer to in the diagram as the “Life Cycle Manager”.  Currently, the Swiz.as class in the framework acts as both the life cycle manager and what I refer to as the “Event Bus” in the diagram. However, this will change soon, where Swiz.as will be used for global variables. The loadBeans method is what starts up the Swiz “introspection engine”, so the Life Cycle Manager can be identified by the class that the loadBeans method is called on. My guess is that this method will not move from Swiz.as, and if it does move to a separate “LifecycleManager” class, the method will still be accessible from Swiz.as.

See, the core methodology of Swiz is to maximize simplicity, and that is why we have microarchitectures and design patterns in the first place. 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 totally counter-intuitive. Initializing Swiz simply by calling Swiz.loadBeans is incredibly simple. That is why I suspect that even if the method is moved to a full-blown LifeCycleManager class, you will still be able to initialize Swiz by simply calling Swiz.loadBeans.

What is a Bean?

Beans in Swiz are MXML files that extend the Swiz BeanLoader class. Within the BeanLoader tags, you have a series of object declarations. Figure 2 demonstrates what this might look like for a delegates bean.

 <?xml version="1.0" encoding="utf-8"?>
<BeanLoader xmlns="org.swizframework.util.*" xmlns:del="com.danorlando.delegates.*">
   <del:UserCrudDelegate id="userCrudDelegate"/>
   <del:StatsCrudDelegate id="statsCrudDelegate"/>
   <del:VideoCrudDelegate id="videoCrudDelegate"/>
</BeanLoader>

Figure 2: In this hypothetical example, the delegates for basic CRUD operations on users, stats, and videos are registered in a file called DelegatesBean.mxml.

The Introspection Engine

Now that you have seen what a sample bean looks like, its easier to understand that when the introspection engine runs, it looks at all objects that have been registered within BeanLoader classes and the BeanFactory creates and holds instances of the objects to be wired up next. In the Figure 1 diagram, I am showing a hypthetical example where four BeanLoaders have been iterated and pooled in the BeanFactory in four categories: Services, Components, Data Model, and Commands.

In the next installment, we will go in depth in the upper half of the diagram and discuss autowiring and the Event model.

Popularity: 11% [?]

Possibly Related Posts:

• Flash Camp Phoenix a Huge Success
• Best Drunk on Software Episode Ever
• Enterprise Flex and the Swiz Framework Architecture, Part 3: Using Autowire and Mediate
• “Flex 4 in Action” (Early Access Edition) Now Available!
• Designing (RED)Wire, Part 3: Advanced Styling Methods for Enhanced User Experience with Adobe Flex and AIR

---

Posted by Dan Orlando on May 1st, 2009 :: Filed under General
Tags :: Enterprise Flex, Swiz
You can leave a response, or trackback from your own site.

---