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"?>
 preinitialize="preinitializeHandler( event )">
 import com.briankotek.swizdemo.config.Beans;
 import org.swizframework.Swiz;
 private function preinitializeHandler( event : Event ) : void
 Swiz.getInstance().loadBeans( [Beans] );
 <mx:Text text="Yay we're up and running." />


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"?>

	<controller:UserController id="userController" />

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 (14) | | Digg It! Digg It! | Linking Blogs Linking Blogs | 20515 Views

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)

  • # 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

  • # Posted By Philip Bedi | 6/4/10 4:10 AM

    Thanks for the tutorial mate, it helped a lot.

  • # Posted By Gaston Quittner | 12/9/10 2:19 PM

    I've got an issue with the loadBeans method. It just won't work. I don't know why, if I use it, no call will be made to the beans. If i don't use it, the call is made, the server builds the entities and all, but won't send it back to flex.

    Any help? I really have no clue why it isn't working.

  • # Posted By Brian Kotek | 12/9/10 2:41 PM

    This is an old article which is talking about Swiz version 0.6.5. We've moved on to version 1.0 and it works a bit differently than the older version did. For example, there IS no loadBeans() method any longer. You'll probably want to look at the docs for the new version and download the latest swc ( If you still have questions after going through the docs, you should ask on the Swiz mailing list so that others can help you as well as myself ( Thanks.

  • # Posted By Gaston Quittner | 12/9/10 4:34 PM

    Ok. Thanks.

    Any specific place I could find examples of using the new version with java as backend?

  • # Posted By Brian Kotek | 12/9/10 5:11 PM

    Not really, because it is difficult to create examples that require a specific server-side platform. It's not very useful anyway, because Flex (and obviously Swiz) are totally independent of what is used on the server. So it works with ColdFusion, Java, .NET, Rails, PHP, etc.

  • # Posted By Brian | 1/8/11 11:00 AM

    Your answer to Gaston seems unacceptable.
    If this "tutorial" is old and doesn't work, why is it taking up space (and frustrating those of us who want to learn)?

  • # Posted By Brian | 1/8/11 11:07 AM

    I have to apologize for my last comment. Didn't see the update for SWIZ 1 beta.
    Again... sorry.

  • # Posted By Brian Kotek | 1/9/11 7:51 PM

    Sure, I probably should have given the link to the Swiz category here in the blog, which has all of the Swiz content I've published: