Last week I was involved in a small Flex project at work and given the fact that this project was small we decided to try out a new framework. The choice was either Mate or Swiz and at the flip of a coin fate decided it was going to be Swiz.

Given the short time (just a day and a half or so) that I was working with Swiz I used a 5 part tutorial by Brian Kotek to get me up and running with Swiz.

My first impression was “Hmm I can’t ctrl+click on classes in eclipse to open the class file” which is sort of a bummer really, because I had no clue how things were wired together. You can still read this back using breakpoints and debugging, but it’s incredibly useful to be able to ctrl+click during development.

Besides that I had to get used to the way things were done in Swiz. For instance comparing things to Cairngorm where the controller is not much more than an event to command mapping, whereas in Swiz you don’t really use the command pattern. The code is mostly done in the controller(s).

In the days after I was browsing the web to read up a little more on Swiz and I came to an article by Sönke Rohde about migrating from Cairngorm to Swiz. The way Sonke deals with Swiz is a bit different than in Brian’s tutorial and it makes things a lot clearer and in my opinion does things in a more proper way. In the end of that article is a good summary of how you should give the different aspects of an MVC framework it’s place within Swiz.

• Declare models, controller, delegates and services in the BeanLoader and load them with Swiz.loadBeans
• Views get the model autowired and can add data bindings.
• Views dispatch events caused by user gestures with Swiz.dispatchEvent or Swiz.dispatch
• Controller mediate events with [Mediate(event="...", properties="...")]
• Controllers get models autowired which need to be changed by the controller.
• If the controller calls a service autowire the delegate
• Delegates autowire services and return the AsyncToken from the service call

This article did not (as Brians article did) meantion things like typing to the interface so that you can always use a different implementation later without having to go through your application and change types everywhere, but this is sort of a given. If you want to see a nice example of using this technique you should read Brian’s tutorials and look for the way he implemented the UserDelegate.

After reading Sönke’s article I’m more enthusiastic about Swiz than I was after the 1,5 days I worked with it. In the end however, the choice of a framework (or perhaps not using a framework at all) is always depending on the project itself. Choose the one that fits the bill!