Swiz vs RobotLegs

Recently I spent some time converting a medium-sized project first to Swiz and then to RobotLegs.  The following is my take on the two frameworks and how I chose a winner.  Right now there are definitely a lot of things I like about both frameworks, and I wish I could pick and choose the features I like best.  I would call it the Peanut Butter Framework Mashup Extraordinaire.

I have considered giving Mate and Parsley a similar go but Swiz and RobotLegs were the two that definitely interested me the most so I’ve done them first.  I’m pretty familiar with Cairngorm and don’t personally like it.  I think I’ve read and tinkered with PureMVC enough to know that it isn’t my ball of wax either.

Keep in mind that I am refactoring an EXISTING project to use these frameworks.  I am not starting a project from scratch.  If I were then I might feel differently.  Maybe.

What is important to me?

The most important things about a development tool, be it an IDE, a library, a repository or a framework is:

1. How quickly can it help me get the job done?
2. How quickly can it help me add new features?
3. How quickly can it help me find and squash bugs?
4. How little code can I write to get the job done?

And that’s it really.  I want to write as LITTLE easily understandable code as possible and I want to be able to easily fix it and add to it.

Don’t code it ’till you need it.

For me writing code is not always a task of reuseability.  If I build something for a project then it’s for THAT project.  If I see that some piece of code could be helpful elsewhere then I will take the time to make that piece a project and allot it its own time.  By carefully choosing what gets “bumped up” into reuseability land I am able to get the job done faster and with less effort.

With that in mind it’s important that the framework I’m using allow me to do that; write code quickly.  That isn’t to say I’ll settle for spaghetti code just because it closes the job ticket faster.  I know I’ll also be the one adding features to this puppy and fixing bugs.  So I want it to stand the test of time.  So the framework will also need to gently guide me to do that as well.

Map Commands vs Mediate Methods

One difference between Swiz and RobotLegs seems to be how they handle “triggered logic”.

Using Swiz you define instances of Controllers in your Bean Map.  In those controllers you will have a number of methods that get called when an event is fired that Swiz captures (mediates).

You can use events to trigger calls to methods in RobotLegs as well but only in certain siturations (Mediator classes).  It seems to instead suggest that you map Commands to Events, a technique which I was first introduced to in Cairngorm.  The WAY this happens is different than Cairngorm, but the idea is roughly the same: When X happens this Command Class is created and executed.

That’s actually how the project was working before the conversion (though it was using a home-rolled solution for that).

Now I LOVE commands.  I really like to use my own command library.  I don’t always want to have to link a command up to an event.  With my library I can play with my commands from anywhere in my code.  Generally I don’t care when a command starts, finishes, etc except from where I actually called the command.  This helps me keep my code-base as small as possible; needless custom events aren’t created when only one place cares about something happening.  When I DO find that event information is helpful elsewhere then I can just dispatch some informative events from the command itself (using whatever the framework of the day is).  With this in mind any tool that lets me to easily continue working in this manner is a win for me.

Using RobotLegs I’m able to map an Event to a Command.  Awesome.  I can even inject some data into it.  Cool.  But the Command needs to be an ICommand.  And I couldn’t find ICommand in the library so AFAIK the commands actually have to extend robotlegs.Command.  Not cool.  I have dozens of commands already written and tied to another library.  I could just change the Commands that need to be triggered by events but that sounds like a royal pain-in-the-ass and additional work == bad thing.

Using Swiz I’m not able to map the commands to events.  I don’t like that.  However I CAN create and execute the commands from the Controller.  The Controller is mapped from the same BeanMask that the model objects are mapped in and it just contains a bunch of methods that get called when events fire (defined by MetaData).  That actually gives me a little more control.  I can inject the dependencies into my existing commands if I want to.  But in my project all of my commands actually have constructor parameters.  So I just inject properties into my Controller and using that and the properties on the dispatched events I handle the execution of the commands.  It’s not incredibly elegant but it gets the job done and there isn’t much code to write or change.

Getting Events Out There

Bubbled events are cool right?  Sure they are technically “expensive” and there are the rare cases of apps fighting each other over bubbled events that they throw at each other.  A “Bubble Fight” I call it.  Personally I’ve never witnessed one.

RobotLegs is very strict about NOT relying on the DisplayObject tree as a means to move event messaging back and forth (bubbling).  Swiz lets you do just that.  Bubble an event up from any attached view and any methods assigned to that event will be called.  Easy-peasy.   That’s another win for Swiz.

Singletons are Awesome

No their not.

Fortunately both frameworks allow you to more elegantly handle Singletons and actually ALL the data that exists in a project.  Using DI (Dependency Injection) you can have objects that the framework is aware of injected right into your classes.  Both use some type of MetaData to define that.  [Autowire] is Swiz’s and [Inject] is RobotLegs, but it comes down to the same thing.

DI allows you to do away with the classic “Singleton” pattern.  Class.getInstance() sucks.  Even when you don’t care about reuseability it still sucks.  As far as the injecting/tagging goes I can’t say that I’ve got a preference.  But for registering these items I like Swiz better.

In RobotLegs you have a class that kind of “kick starts” things.  One popular place to put the items to be injected is there.  I understand, however, that you can actually do this in a number of places in a number of ways.  That sounds like trouble to me.

In Swiz the accepted way of doing this is in an (M)XML document; the BeanMask.  This document will define all of your “model” objects.  These are the objects that can be [Autowire]d.  That seems clean to me and I like it.  You can have multiple Bean Masks if your project gets large, but at least you’ll know where to look for stuff.

Code from Behind vs Reach Around

I’ve got a number of views that are small.  Small enough that I just put the necessary view logic in a <Script/> tag.

Sometimes that logic will grow and grow and I’ll just pull it out into it’s own class.  Usually I just do a code-behind.  (The MXML class extends an ActionScript class which has all the logic in it.)

Previously I had a “Global Event Dispatcher” that my views listened to.  Methods were called when those events were dispatched from that “Global Event Dispatcher”.

RobotLegs doesn’t like that.  I need to have a Mediator class for my logic.  Then I need to bind that mediator class to the view.  But not actually IN the view.  Or even in the mediator (though the mediator should have a REFERENCE to the view).  The binding takes places somewhere else.  If I don’t play by those rules then I don’t get the benefit of mediated methods for my view.

Swiz doesn’t care.  I can just stick [Mediate] on any public view method (<Script/> or code-behind) and it will work just fine.  I’m not opposed to mediator classes.  I think that is a fine (and cleaner) alternative to a code behind.  But I don’t want to HAVE to do it that way.  Unfortunately, that method DOES need to be public, which I DON’T like.  I think I can get over that, but it’s essentially an event handler.  It’s not something that anyone outside of that view needs to know about.

Services

Ok, I honestly didn’t put either framework through the paces when it came to working with my Services.  All of my service handling is already done in a way that is already clean and I saw no need to change that at all.  This wasn’t an important part of either framework for me.

Best Practice vs Get ‘er Done

Shaun Smith had a great piece about “why RobotLegs”.  And I couldn’t help but get fired up about his reasons.  They are good ones.  But they seem like good reasons on paper, not necessarily in practice.  Like I said, if I had started this project out fresh instead of trying to port it then I might feel differently.  But when I look at all the code I would have to change/add using RobotLegs that shows me that there might be a lot of code that I shouldn’t have to write.

When I ported everything to Swiz it took me a couple of hours and I had things rolling.  I was able to change just a portion of my application to rely on the framework.  It worked alongside what I already had.  But it took me the better part of some valueable sleepy-time to get RobotLegs working.  And even then I still had mountains of Mediators to create before the app was truly “working”.  Don’t think I’m a hater.  I DO really like what RobotLegs is all about.  But it’s just not for me; it doesn’t fit my workflow or my coding style.

Swiz does.

It’s late

If I’ve gotten anything wrong describing the usage of either of those frameworks then please correct me.  I admit that I am a total n00b at both of these.  I tried to keep it general and relatively vague; there are plenty of other resources that explain how these things actually work much better than I could.

Sleepy time.