Why Boiler is better than Robotlegs. Pt. 1

Haha! That’s gunna turn some heads.. I hope.

Herein I set out to explain why I’m building Boiler. Other than the obvious fun of writing a framework, I have some very specific reasons.

I could be wrong of course, Robotlegs is so good (and it’s well past the alpha stage, unlike Boiler) that it’s a tough call. However, why would I bother if I wasn’t trying to improve on something awesome?

Doubling intent

Imagine this is a mediator I just wrote:

package views {
    public class WidgetMediator {

    [Inject]
    public var notifier:IEventDispatcher;

        private var view:Widget;

        public function register(view:Widget):void {
            this.view = view;

            view.addEventListener(MouseEvent.Click, handleClick);
        }

        public function deregister():void {
            view.removeEventListener(MouseEvent.Click, handleClick);
        }

        protected function handleClick(event:MouseEvent):void {
            notifier.dispatchEvent(event);
        }
    }
}

I consider this class to have all the markings of a mediator. It’s name ends in mediator, that should be enough… But there’s more. It’s in the views folder where a lot of folk stash their mediators. It expects to be registered against a view:

register(view:Widget)

Despite not inheriting from a Mediator Interface, it’s a mediator. In the land of Ruby, they call it ‘duck-typing’. It looks like a duck, quacks like a duck, it’s a duck.

So in Boiler, we use conventions to invert control. When you start using Steam, you follow convention to describe the intent for a class. Steam, by the way, is the reference desktop framework for Boiler, like MVCS is for Robotlegs.

The above mediator needs only be ‘Mapped’ using SwiftSuspenders and Steam will configure injections and view mappings ‘because it looks like a mediator’.

In Boiler:

lifetime.mapClass(WidgetMediator,WidgetMediator); // A little note on the first param later.

In Robotlegs:

mediatorMap.mapMediator(WidgetMediator);

It’s a tiny difference, really, except now we don’t have to inherit from anything to look like something. Later I’ll show that we also don’t let ourselves get caught by inheriting from sugar classes.

The first thing that Boiler gives you, is no more polymorphic dependencies that only serve to duplicate intent.

When you want to extend the framework behavior, remove behavior, or use certain behavior in only some modules, the benefits of avoiding framework polymorphism become clear. Later on, I’ll demonstrate this with examples that extend or modify the framework.

About that first parameter

Why does SwiftSuspenders require an interface separate from the class to instance? This example is a mediator, all of it’s dependencies are injected. It’s never injected into another class. Where it’s built is where it’s stored, in a generic, testable class… So I can’t see a problem with lifetime.mapClass(widgetMediator);

Why Boiler is better than Robotlegs. Pt. 2

I’m starting out with the “not terribly awesome” and perhaps even “that’s crap!” stuff. That is, you might think I’m losing my mind at this point. Remember these are things that I love about Boiler. You might not.

I promise you, though, that the final two articles in this series will be epic. I’ll show you how to extend Steam using ‘commands’ as an example. I’ll also show you how to integrate some syntactic sugar without making the framework brittle.

Sugar be damned.

It’s sugar that I want to discus in this post.

Sugar is usually not the same concern as the base class.

Mediator#addViewListener makes me think that Mediator is-a view listener.

Mediator#addContextListener makes me think that Mediator has-a context bus AND is-a contextListener.

In Steam, neither is true. Mediator is-a class that expects to be told when a view of a specific type has been added to the stage. That’s all it is, period.

Without sugar, there is no Mediator Interface, only duck typing as I explained in the previous article.

It’s all about SRP

Sugar can hide the obvious from tools.

This ones pretty fluffy, purely a matter of taste.

Again with the Mediator sugar from Robotlegs, I would usually start typing:

addContextListener(MyEvent.EVENT_NAME,eventNameHandler);

IntelliJ would highlight the ‘eventNameHandler’ so I could select ‘create method’. Which is great. I can automatically stub out:

public function eventNameHandler():void {
}

That’s not bad… Except if I had used:

myContextBus.addEventListener(MyEvent.EVENT_NAME,eventNameHandler);

IntelliJ would offer to stub out:

public function eventNameHandler(event:MyEvent):void {
} 

Boiler want’s us to avoid hiding language conventions. Kthx?