To begin this series on Swiz, I whipped up a couple of mockups using Balsamiq to show what the end result should be. It's going to be a pretty simple user manager interface. Let's have a quick look at those images and then we'll move on to setting up an application shell for this using Swiz.

When the app loads, I want to see a panel containing a datagrid that shows a list of Users:

When we click on a user in the grid, the state changes to show a detail panel beneath the datagrid panel:

If we double click on a user in the grid, or select a user and press the "Edit User" button, the state changes to show an edit panel beneath the datagrid panel:

If we click the "Add User" button, we still get the edit panel, but obviously it's contents will be empty so that we can enter the new user information:

One behavior that isn't shown is that if we click on a user and press "Delete User", the user is deleted and the state reverts back to the initial state of just showing the datagrid panel.

Nothing too crazy going on here, but it's complex enough that I'll be able to show how Swiz handles a variety of things. I'm going to assume you know how to actually create a new project in Flex Builder or your tool of choice, as this isn't really meant to be a tutorial on Flex basics. If this is a problem, let me know or check the Flex documentation.

To begin, we need to download the Swiz swc component and place it in the /libs folder of our Flex project. Assuming you're using Flex 3, you don't need to do anything else. (On Flex 2, you'll need to specify some compiler arguments to get the Swiz metadata to be included, see the Swiz docs for full details.)

One of the nice things about Swiz is that it is a very "open" framework, meaning it doesn't do much dictating to you about what to do. It is flexible enough to allow for a range of programming styles and doesn't force any conventions down your throat. The only real requirements are that you create a file to tell Swiz what classes you want Swiz to manage, and that you initialize the framework when your application's preinitialize event fires. Luckily, this is simple:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application 
 xmlns:mx="http://www.adobe.com/2006/mxml" 
 layout="absolute"
 preinitialize="preinitializeHandler( event )">
 
 <mx:Script>
 <![CDATA[
 import com.briankotek.swizdemo.config.Beans;
 import org.swizframework.Swiz;
 
 private function preinitializeHandler( event : Event ) : void
 {
 Swiz.getInstance().loadBeans( [Beans] );
 }
 
 ]]>
 </mx:Script>
 
 <mx:Text text="Yay we're up and running." />

</mx:Application>
		

As you can see, you simply create a handler for the preinitialize event and call Swiz's loadBeans() method. Now your next immediate question is probably, "where are the beans"? Glad you asked! You can see above that I'm importing a class named Beans. This is where you actually list the Flex classes that you want Swiz to manage. If you're familiar with Spring or ColdSpring, this will be somewhat familiar to you. There are a few differences that I'll talk about in a moment, but let me show you my initial Beans.mxml file:

<?xml version="1.0" encoding="utf-8"?>
<BeanLoader 
	xmlns="org.swizframework.util.*" 
	xmlns:mx="http://www.adobe.com/2006/mxml"
	xmlns:controller="com.briankotek.swizdemo.controller.*">

	<controller:UserController id="userController" />
	
</BeanLoader>
		

By specifying components here, you're letting Swiz know about them. This is how Swiz is able to work it's magic later when it comes to things like autowiring and dynamic mediators. If we wanted to, we could stop right here. These two steps are all the framework really forces you to do. Just about everything else from here is up to you. Swiz offers some really nice features to help you do additional things, but technically this is all you have to do.

Of course, it would be kind of pointless to stop there! You can see that I listed one class in by Beans.mxml file, the class UserController. I've specified an id of "userController", which can also be thought of as a "bean ID". Again, to folks familiar with Spring or ColdSpring, this will sound familiar. But don't worry if you don't know what that means, I'll talk about where you might use the bean ID in an upcoming entry.

This is already been a bit long so I'll sign off here for today. But I'll leave you with a thought. I've mentioned already that Swiz is, at it's heart, a dependency injection (DI) framework. That's where the magical stuff like "autowiring" happens. But how might that actually happen? To those familiar with DI, you might think that our Beans class would need to specify all of the dependencies, similar to how Spring/ColdSpring uses an XML configuration file to describe all the dependencies. Happily, we don't! I alluded to it earlier, but Swiz makes use of Flex metadata (in the form of annotations) to resolve all the dependencies. In the next entry, we'll start getting into the meat of Swiz by looking at how to use annotations to resolve dependencies. In the meantime, you can start saying goodbye to any clunky ModelLocator singletons that are referenced everywhere in your applications, headaches related to component creation order, and ugly boilerplate code!

Comments Comments (6) | del.ico.us del.icio.us | Digg It! Digg It! | Linking Blogs Linking Blogs | 6198 Views

Comments

  • # Posted By rakhtar | 1/8/09 1:00 PM

    Good article (short and sweet). Looking forward to the next one!

  • # Posted By Stephen Judd | 1/9/09 4:08 PM

    Thanks Brian...this will definitely be a useful and interesting series. I look forward to the next post...I'm following along.

  • # Posted By Chris Scott | 1/10/09 1:33 PM

    Hey Brian, great start! One quick point, you don't need to call getInstance(), anything you need to do directly to Swiz has a static method, so Swiz.loadBeans( [ Beans ] ); should be the preferred format.

  • # Posted By Brian Kotek | 1/10/09 3:31 PM

    Ha! Thanks, Chris, I hadn't even noticed that.

  • # Posted By Gareth Arch | 1/12/09 12:30 AM

    Not that it's that big of a deal, but I was just wondering...does the Beans file need to be MXML or can it be an AS file? I thought there may be a time when a AS file would be preferable to an MXML file (not that I can think of any off-hand, but who knows :) ).

  • # Posted By Mark | 11/30/09 5:09 PM

    I was about to say the same.

    --
    Mark Kwon
    http://www.venditascarpe.com