AS3-Signals is a recent project by Robert Penner as an alternative to Flash Player’s native event system. While I don’t personally have (m)any problems with events, I have been curious about Signals and keeping an eye out for an opportunity to try it, especially in conjunction with Swiz. That opportunity presented itself a few weeks ago, when Joel Hooks finally showed me the world that Robotlegs can be used without extending framework classes all over the place. As he says in the post, I had been asking to see that for a long time, because I cringe at frameworks that mandate lock-in via inheritance.

In looking at Joel’s sample application (which I think is very good), I noticed that it was very similar to a Swiz application. The application is configured using a context class, which is virtually equivalent to a Swiz instance used to configure an area of a Swiz application (or a whole application). So I spent about 15 minutes and took the latest Swiz SWC I had, created a Swiz instance that mapped to his context, put it in the context’s place, and voila; I had the same application running on top of Swiz. Literally the only other thing I had to do was to add a single [PostConstruct] metadata tag. You can see the striking similarities below. Edit: I have now also included the same Swiz configuration as it would look in ActionScript.

Swiz config in MXML

RobotLegs config

Swiz config in ActionScript

You can even take the resulting application and switch the framework it’s running in by simply commenting/uncommenting the ImageGallerySwiz and ImageGalleryContext lines in index.mxml

Application :: Source

Working with Signals couldn’t be simpler, and Swiz supports them right out of the box. In fact, I couldn’t help but be amused by the fact Swiz had better native support for them than RobotLegs did. They are simply defined in a BeanProvider like any other dependency, and then work as expected. The [PostConstruct] I added was on LoadGalleryCommand’s execute() method, and it replaces the last line of ImageGalleryContext’s startup() method.

Summary

I really like the fact that applications can be somewhat interchangeable between the two frameworks now that we’ve settled on [Inject]. I think a reasonable degree of portability is a sign of a good framework, and based on this example you can see that both RobotLegs and Swiz meet that criteria. The obvious question then, is why pick one over the other? Some of it surely comes down to personal preference, but beyond that I think it is a question of power, scalability, adaptability and developer productivity. In future posts, I will show how Swiz is the clear winner in those categories.

Enjoy!

Passive View is another presentation pattern that can be used to increase the testability of graphical applications. It does this primarily by extracting all logic and state from your views, making it pointless to test the view itself. In fact, in the article linked above, Martin Fowler says the following:

With the view reduced to a dumb slave of the controller, you run little risk by not testing the view.

You instead test the component to which the logic and state have been extracted. This component can be referred to by names such as mediator, presenter or controller but the name itself is irrelevant. What is important is that it is not a view component (meaning it does not exist on the display list, in Flash/Flex specific terms), which are inherently hard to unit test. In the example application I have created I refer to these components as mediators.

Example Application

For this post I have simply converted the Swiz example application I created using the Presentation Model pattern. The conversion took maybe 30 minutes, which includes looking up some of the specifics of the pattern, because I had not actually implemented it before.

Application :: Source

Motivations

One of Swiz’s biggest strengths is the flexibility it affords you when using it. Rather than enforcing (or even suggesting) a particular architecture, it provides tools and utilities that help you to create well architected applications. I think showing the same application built with different (albeit similar) presentation patterns demonstrates this point quite well. I will also admit that I was influenced by the RobotLegs Best Practices document in selecting Passive View as the pattern to demonstrate since they demonstrate/promote the pattern there. Hell, I will even admit there was a bit of “anything you can do, we can do better” sentiment on my part. That is not meant to take anything away from the RobotLegs team as they are certainly a smart bunch of guys, but I wouldn’t have joined the Swiz team if I didn’t think it was the best thing out there.

Thoughts on Passive View

I sort of like that your views become plain MXML with no logic, state or external references whatsoever when using the Passive View pattern. What I don’t like is what your mediator/presenter/controller becomes in order to purge your view of those things. I feel like you end up with a frankenstein class that is part (presentation) model, part controller and part code behind.

It is not truly code behind since it uses composition rather than inheritance, but it feels the same. You are reaching into the view to add listeners to its child components, setting properties directly on its child components, etc. Handling events from those child components is like a controller, but you also end up storing some state for the view as well. You could obviously break that out into a separate model class but for most views that is going to be massive overkill. I suppose that presentation models are or can be somewhat of a controller and model combination as well too though. I think adding all the knowledge of the view and its internals is what creeps me out most.

I also feel like Passive View fights against the platform a bit. Since the view has no references to anything, binding is not an option. The view can only be updated by user interaction or manually from the mediator, and even for the extremely simple example I created this felt very tedious. I also wonder if testing the mediator could not potentially be complicated by needing an instance of the view it mediates for operation. Flex Unit 4 likely overcomes much of what would have been painful in the past in this area, but I feel like removing view components from the testing process completely is ideal.

In summary, I think Passive View is a decent pattern, but I won’t be abandoning Presentation Model to use it. In my opinion the drawbacks outweigh the benefits, but the same may not hold true for your particular needs and/or preferences.

Further reading

Be sure to read the Martin Fowler piece linked at the beginning of this post (and anything else by Fowler you have time for), and for another example of the Passive View pattern in Flex check out Paul Williams’ post on the topic.

Enjoy!

About a month ago I was introduced to the Swiz application framework for Flex. Within an hour or so, I was not only sold on the simplicity and effectiveness of the framework, I was digging around in the source adding features. Shortly after that I started collaborating more closely with Chris Scott, creator of Swiz and a coworker of mine, and Sönke Rohde, the other Swiz team member. The three of us have been cranking away adding new features ever since and have a lot planned for the coming months.

Now that introductions are out of the way, let’s look at some code. I’m really not going to try and explain much of anything here because I’ve done that (heavily) in the code and comments of the application. In the recent past I have repeatedly found myself frustrated with a lack of examples when reading about new frameworks or projects people are promoting. I learn best and quickest when I can see something in action and figure out how it works, so I created this example for other people like me. If you have questions, comments or suggestions about the application you can obviously post them here, or you can post them in the Swiz Google Group where I will also be posting a link.

Lastly, a couple of disclaimers.

• Only the Employees view of the application contains anything. I only created multiple tabs to facilitate the mode monitor at the bottom of the app.
• I’ve placed the ASDocs above the metadata tags for the sake of readability and simplicity. In a real application the ASDocs (unfortunately) go between the metadata and the code.

Application :: Source