Thursday, January 29, 2009

More Swiz features, or Swiz 0.0.5 Part 2!

Since my last post was getting a bit long, I said I would get a second installment out 'soon'. It took slightly longer than I hoped to get together, but it gave me a chance to put more into Swiz, that I can also blog about 'soon'!. I left you hanging a bit after mentioning Swiz's new Prototype bean, so lets get right down to business. If you've used Spring or ColdSpring before, you should be well aware that they manage both singleton and non-singleton beans. Spring 1.0 and ColdSpring provide a 'singleton' attribute for the element in your config file. The singleton attribute defaults to true, meaning there will only ever be one instance of that bean in the factory's cache, but if you change it to false, the bean definition becomes a prototype for a new instance that is created every time getBean is called. In Spring 2, the semantic was shifted a bit, and now the attribute is called 'scope', setting it to 'prototype' is the same as singleton=false. I like the shift in terminology, it's more expressive of what Spring is actually doing.

Handling prototypes, or non singletons, is pretty much a core function of an IoC container, but Swiz has a little secret, we've been getting by without it. This has a lot to do with the route I initially followed to build Swiz. Being that Flex already has a built in xml language which you use to define object instances, it seemed very natural to me to leverage MXML for Swiz's configuration. However, when you supply objects to Swiz in a BeanLoader, you are defining instances, which are cached as singletons. Even though this is extremely simple, and I could easily argue the point that 90% of all objects managed by IoC frameworks are in fact singletons, there is also plenty of reasons why you man need a unique instance every time a bean is retrieved from Swiz. For instance, what if you wanted to wire up a separate instance of a controller for each view in a tab navigator. Well, with Swiz's new Prototype bean, you can! Here's an example of the new Prototype bean in action:

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

    <!-- hello service -->
    <mx:RemoteObject id="widgetService" destination="widgetService"/>

    <!-- delegate for the hello controller -->
    <delegates:WidgetDelegate id="widgetDelegate"/>

    <factory:Prototype id="widgetController"
                className="foo.controllers.WidgetController"/>

</BeanLoader>

I've defined three objects, a delegate, a remote object, and a controller, if you've worked with Swiz in the past you can already guess how they are being wired together. However, instead of defining the controller directly in MXML, I have defined a Prototype bean, providing an id and className. This should look very familiar to users of Spring and ColdSpring, there's just one big difference to take note of. In Swiz, a prototype is by default non-singleton. You will always get a new instance anytime this widgetController is injected into a view or another bean. It's important to take note of this difference. Your normal beans are always singletons. Prototypes are by default definitions of non-sigletons. Which makes a whole lot of sense semantically. However, if you would like you, can alternately use Prototype to define singletons, by setting the attribute singleton="true". As a matter of fact, if you took this route, your BeanLoaders would look a whole lot like your Spring or ColdSpring config files! I hope you find some great uses for the new Prototype, and check back for the next installment, Swiz's new IInitializingBean interface!

Good to end on another cliffhanger, right?

5 Comments:

Blogger Gareth said...

Quick question on the factory and when to use it...

I'm creating an AIR application that allows drag 'n' drop of pictures into a tilelist. I'm handing the dropped images off to a mediator in my pictureListController. I'm wanting to set each of my dropped images to a "Picture" class in an arraycollection. Would this be a good use of the factory + autowiring capability or am I completely off base?

Thanks.

7:28 PM  
Blogger Francis said...

Chris, your work on Swiz is fantastic. I'm working on HydraMVC.com and finding that using Hydra for a view-layer MVC and Swiz for dependency injection might work really well. Basically, I think you're brilliant and I'd like to take a train ride to Philly and buy you a beer and discuss some architecture and maybe working together. Would you be up for that? We've got some huge (million-dollar) projects that we're in the process of engineering and I'm trying to ensure that we have the proper methodology in place. Let me know-

5:04 AM  
Blogger Chris Scott said...

Hey thank you! If you want to come up to philly, give me a shout and we'll get together. Do you know my email address? You can get it from the google code or groups site if you don't.

5:53 AM  
Blogger moxie said...

Hi Chris,
I'm the RIA editor of infoq.com. Like to talk to about swiz. Drop me a line.

Moxie

1:45 PM  
Blogger Chris Scott said...

Hey Moxie, can you send me an email so I have your address? It would be great to get something into infoq.

5:52 PM  

Post a Comment

<< Home