Swiz Framework

It’s here! The alpha release of Swiz 1.0.0 is officially in the wild! First, links.

Swiz 1.0.0 alpha source code
Swiz 1.0.0 alpha example projects (SwizDemoApp & SwizDemoAppAS3)
Live Demo App – Flex 3
Live Demo App – AS3

(The examples are heavily commented so view the source!)

Swiz 1.0.0-alpha represents the current state of a clean slate rewrite of the Swiz Framework. While discussing and planning new features and refactorings a few months ago, we decided we’d rather start fresh. Accommodating things like modularity and pure AS3 projects, as well as some ideas we had in mind were more easily accomplished (and let’s face it, more fun to do) by starting with a blank slate and building only what was necessary, in the cleanest way possible That being said, this release definitely lives up to its alpha name, and will not allow you to simply drop the SWC into an existing Swiz project. (I mean you can, but nothing will work.) So let’s talk about some changes.

Quick disclaimer: I am *positive* there are features and/or changes I am forgetting to mention here. Generally speaking, if something is missing from the framework it most likely has just not been implemented in the new code base yet. Please direct all questions, concerns and suggestions to the mailing list.

Autowiring

Autowiring has been greatly improved. A good way to think about autowiring now is that it is similar to the <mx:Binding> tag in Flex. The bean attribute has been “renamed” to source, but bean will still work in order to ease migration. Eventually, you will start getting deprecation warnings if you use bean. We have also added support for default attributes, so [Autowire( "someModel" )] is equivalent to [Autowire( source="someModel" )].

destination

There is an optional destination attribute. The destination attribute allows you to create a class-level [Autowire] tag, and tell it where to assign the autowired value. We did this because it was pointed out that users were commonly creating public, bindable properties that served no purpose other than being an autowire destination and a binding source. You can use this format to do things like this:

Dot notation

As you may have noticed in the above sample, the source and destination attributes both support dot notation. This was a highly requested feature, and also vital to supporting the destination syntax. There is no limit to the number of levels you can drill down, but it should generally only be used as necessary. We have also removed support for the property attribute, since it is negated by the dot notation support.

Setter injection

Swiz now supports single argument setter injection as well. The only reason it is limited to single argument methods is that we would like to get community feedback before implementing further support. Should support be added for additional argument methods? Usage is as follows.

Planned future improvements

In addition to the twoWay and view attributes that exist today, we also plan to add two new attributes in coming releases. First is a bind attribute that, if set to false will cause Swiz to perform a one time value assignment with no bindings created. The default value is/will be true. Second will be a lazy attribute, which will also default to true. Now that Swiz is modular, one of the biggest remaining things to implement is inter-instance communication. We will be creating a system that allows Swiz instances to share and inherit beans, as well as some other potential communication mechanisms. The lazy attribute is related to that system in that, if set to false it will cause Swiz to throw an error if that particular dependency is not available when the tag is processed. The default behavior is that Swiz simply makes note of that unfulfilled dependency, and as new objects are added to the system they are checked against the missing dependencies. This allows you to define beans/dependencies in any order and not worry about precedence.

Custom metadata processors

This, in my opinion, is the coolest thing in Swiz 1.0.0. What we have done is to open up the exact mechanism Swiz uses to implement tags like [Autowire], [Mediate] and [VirtualBean] so that you can create and process your own custom metadata tags. There will need to be a future post dedicated to this topic and the reflection system it relies on, but for now be sure to check out the examples. There are two custom processors in the example apps that show how easy it is to create these powerful framework extensions. When creating your own though, don’t forget you have to add compiler args in order for mxmlc to retain your custom metadata tags.

VirtualBean

If you were paying attention in the previous paragraph you may have noticed mention of a new built in tag, [VirtualBean]. As I alluded to above, it is not ideal to reference bean properties in [Autowire] tags. Not only does it create a reliance on that specific object structure which will break if somebody changes it, it is also usually not appropriate for a view or other destination to have that implementation knowledge in the first place. Enter the VirtualBean tag. When placed on a public property of an existing bean it transforms that property into an “independent” bean of its own, removing the need for dot notation and the associated concerns that go along with it. If your view only needs a collection or two from your model there is no longer any reason to wire in the whole model or to include a property name reference in your [Autowire] tag. Usage is as follows.

Instantiation and configuration

Lastly, you will notice that instantiation and configuration of the framework look quite different in the demo apps. This is explained a bit in the comments of the apps but I will repeat it here: these aspects will likely change a bit before the final release. We have not yet implemented SwizConfig at all in this release, but that will be a part of the final release. Other minor details may change as well, but creating an instance of the framework will remain as dead simple as shown in these demos.

Check it out!

So that is it for now. Take a look at the heavily commented demo apps. Browse, download, clone and otherwise examine the framework code. We are eager to get your thoughts, feedback, submissions, patches etc. so don’t be shy! The team’s immediate tasks are to further clean up the code you see today and smother it in unit test coverage, so there is still time to influence the API! Give it a spin and tell us what you think!

Enjoy!