vWork Development

A pattern for handling validations in an associated model ...or how I discovered ActiveRecord::Rollback

Wed, 28 Sep 2011 16:26:27 +1300

Recently I struggled a bit to find an elegant and working solution to validate an associated model when destroying another model’s instance. The two models were Account and User and I needed to validate the Account whenever I delete a User.

The two models look like this - very much simplified:

class Account < ActiveRecord::Base
  has_many :users, :dependent => :destroy
end

class User < ActiveRecord::Base
  belongs_to :account
  has_many :roles # these contain authorization roles, such as ‘admin’
end

The given rule to validate was:

An account must have at least one user that is an admin

This rule makes sure an account always has one administrator that can access all parts of the application.
When someone deletes a user within the app, and this user happens to be the only administrator, validation should prevent this from happening.

I could have implemented this in the User model, for example like this:

class User < ActiveRecord::Base
  belongs_to :account
  has_many :roles # these contain authorization roles, such as ‘admin’

  before_destroy :make_sure_account_would_still_have_admins

  private

  def make_sure_account_would_still_have_admins
    self.account.users.admins.count > 1
  end
end

But I didn’t want to do this. Firstly I wanted to use ActiveRecord’s validations and secondly I wanted to put this logic into the Account model. After all, it’s the account that becomes invalid if there are no more administrators.

Validating in the account model

I added a custom validation and an association extension to the account model:

class Account < ActiveRecord::Base
  has_many :users, :dependent => :destroy do
    def admins
     self.select { |user| user.has_role?('admin') }
    end
  end

  validate :has_at_least_one_admin_user

  private

  def has_at_least_one_admin_user
    if users.admins.count < 1
      errors.add(:users, "must contain at least one user of type 'admin'.")
    end
  end
end

So, if an account doesn’t have a user with the ‘admin’ role, the account will be invalid.

Triggering the account validation from the user model

Now I needed to get this validation triggered whenever someone tries to delete a user. The problem with this was, that the Account model would only be invalid after the user was deleted. If I used validates_associated :account, deleting the last administrator would have passed. That’s because Rails validations are run before the actual operation happens - and at this point the potentially last administrator I was going to delete still existed. E.g. if I ran @last_admin_user.destroy, the associated account would still be valid at validation time, because that user actually has not been deleted, yet.

So I thought, the solution would be to run the validation from an after_destroy callback.
Here, the part I struggled with was that after_ callbacks can only cancel transactions when they raise an error - returning false in an after_ callback is not enough. But of course, you don’t want to end up catching errors whenever you call a simple destroy on the user model.
It turns out, there’s a special error you can raise that doesn’t get passed on. It only causes the transaction to roll back. This error is:

ActiveRecord::Rollback

When I raise this error in the after_destroy callback, the transaction will be rolled back and I do not have to worry about catching errors.

The user model now looked like this:

class User < ActiveRecord::Base
  belongs_to :account
  has_many :roles

  after_destroy  :trigger_rollback, :if => "account.invalid?"

  private

  def trigger_rollback
    account.errors.full_messages.each { |message| errors.add :account, message }
    raise ActiveRecord::Rollback
  end
end

This mechanism works beautifully for this use-case while keeping responsibilities in the models they belong.

Mobile has no chance of taking off

Fri, 23 Sep 2011 13:52:22 +1200

Mobile has no chance of taking off

On the benefits of refactoring

Fri, 23 Sep 2011 08:15:00 +1200

You can’t build an office block and then decide you had better put in some concrete foundations afterwards.

You can, however build a large scale app and decide you want a different foundation along the way.

When you start an agile project, you “pitch a tent in dirt”.

E.g. write a simple app that lets users drag a ‘job’ - which only has a name and id - onto a timeline.

You then itterate, turning the the tent ever so slowly into the office block ( e.g. vWorkApp ). You get to revisit every aspect, and you must revisit it.

If you don’t, you’ll have an office block sinking into the mud.

Why Boiler is better than Robotlegs. Pt. 2

Mon, 08 Aug 2011 13:14:43 +1200

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?

Why Boiler is better than Robotlegs. Pt. 1

Sat, 06 Aug 2011 13:54:10 +1200

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);

Static Controller in Robotlegs

Thu, 23 Jun 2011 07:45:11 +1200

I’ve been away for a while in the land of the Ruby Object model and Rails. Upon my return to some Flex development, I decided that, although Robotlegs MVC ‘Controllers’ are really nice, they require too much boilerplate. One thing I found in RoR, is that although they use static controller classes with many command methods, most folk follow convention and avoid introducing wads of business logic and tightly coupling their code.

The good things about RL-MVC Commands

RL-MVC Commands enforce loose coupling. It’s really hard to end up with complex, tightly coupled controllers when every ‘action’ is a short lived class.

Commands are dynamic. You can change the existing command set on the fly. I’m not sure where this is useful, I don’t take advantage of it, but that’s not to say that other people do not.

The tradeoff

With awesome power comes diminished responsibility. Yeah, that decoupling that Commands give you, removes the need for you to pay as much attention to OO and MVC best practices. Instead, you pay the price by having quite a lot of boilerplate:

One command class per ‘action’ (read: method)

I never did mind this tradeoff. Now It’s wearing thin. Our app is big, and there is a lot of boilerplate. After spending some time learning to write Ruby DSL’s it’s really grating to see that a simple and sensible idea reads so badly in code. If I was in Ruby I would have something like:

# controller_map.rb

map RubbishReminderEvent, PutTheRubbishOutCommand

# put_the_rubbish_out_command.rb
class PutTheRubbishOutCommand
  def initialize 
    house.nature_strip << house.rubbish_bin
  end
end

Minimal boilerplate, just intention. Actually, with a decent DSL, you could do away with all of the boilerplate.

However if you look at Rails, events (http requests) are routed by “concept”. In the de-facto Rails convention a “concept” is a resource, but it does not need to be. The ‘routes’ tell Rails how to map incoming events to controllers.

In Rails, the controllers are classes, by “concept”, with action methods. This runs the risk of being abused, and it sometimes is. However, people who care do not make a mess of their controllers. So I decided to assume my developers are good people, and make a compromise to remove some boilerplate.

The boilerplate

As a reminder, this is the boilerplate I’m talking about

    import ....  // boilerplate
public class PutTheRubbishOutCommand extends Command { // Boilerplate

            // Boilerplate
    [Inject] 
    public var event:TimerEvent;

            // Often repeated, not 'DRY' 
    [Inject]
    public var rubbishModel:RubbishModel;

            // The only bit of actual 'intent'
    override public function execute():void {
        rubbishModel.putRubbishBinOnNatureStrip;
    }

}

Static Controller

I propose using a Static Controller. Here, “static” is an antonym of “dynamic”, not the keyword

This is more like a Rails Controller which groups ‘action methods’ and reduces boilerplate:

public class RubbishController extends Controller {

    [Inject]
    public var rubbishModel:RubbishModel;

    public function RubbishController() {
        addMethod(TimerEvent.RUBBISH_NIGHT, putTheRubbishOut);
        addMethod(HomeOwnerEvent.GO_TO_WORK, bringTheRubbishIn);
    }

    private function putTheRubbishOut(event:TimerEvent):void {
        rubbishModel.putRubbishBinOnNatureStrip()
    }

    private function bringTheRubbishIn(event:HomeOwnerEvent):void {
        if (!rubbishModel.rubishBinIsOnNatureStrip())
            return;

        rubbishModel.putRubbishBinRoundBack();
    }


}

I think this looks good. At this point I should apologise to Jesse Warden for admonishing him when he suggested to a conference room at FATC that it was o.k. to do this.

I still think it’s not “o.k.” because if you don’t grasp the value of seperation of concerns, you will make a mockery of this approach to controllers. If you’re starting out with Robotlegs, do not use this approach!

Addendum

Extra reading: How I aim to implement the static controller

The heart of a Static controller is Controller which looks a bit like this:

public class Controller extends Actor {

    public function dispose():void {
        eventMap.unmapListeners();
    }

    protected function addMethod(eventType:String, callback:Function, eventClass:Class = null):void {
        eventMap.mapListener(eventDispatcher, eventType, callback, eventClass);
    }
}

All it does is give you the ‘addMethod’ event and allows ControllerMap to tear it down via ‘dispose’ as the context dies.

addMethod is a similar to CommandMap#mapCommand, except it doesn’t map a class, it maps a method.

Also, I need to extend Context to provide/manage ControllerMap.

ControllerMap collects and disposes of Controllers. It won’t do much more than:

public function mapController(controllerClass:Class):void {
    injector.mapSingleton(controllerClass);
    controller:IController = injector.getInstance(controllerClass);
    controllers[controllerClass] = controller; // for teardown later
    }

I realise that some people may consider the ‘routing’ and the controller to be different responsibilities. As it stands, I cannot figure out a way of keeping routing seperate, because the Controller#actionMethods have to have a ‘thisObject’ of Controller. It would mean a really dopey looking router method like this:

addMethod(TimerEvent.RUBBISH_NIGHT, RubbishController, RubbishController.putTheRubbishOut);

Which would get worse when you need to enforce the event type:

addMethod(TimerEvent.RUBBISH_NIGHT, RubbishController, RubbishController.putTheRubbishOut, TimerEvent);

yick

All Praise the Almighty Click!

Mon, 23 May 2011 10:19:44 +1200

All Praise the Almighty Click!

Agile, what it means to us.

Thu, 28 Apr 2011 07:24:00 +1200

We’re seeing a lot of to-ing and thro-ing about Agile, it’s success and failure. There are a lot of blogs, posts and tweets which let anyone who wants to, throw it away and dismiss it out of hand.

From our fledgling point of view, the point is being missed.

To work, Agile must be all about allowing a team to do what it naturally wants to do.

That’s it in a nutshell. You can’t use Agile to get a team to toe the line. You can only use it to nurture the natural instincts of a team.

So be very careful about the team you pick. Cultivate a team that will align itself with the business goals, often something like:

making money,
shortest path to making lots of money
doing so sustainably

The team’s instincts will likely include pride. So your business needs to add to its goals:

making product the team can be proud of.

Then really, Agile is just a matter of trusting people. If your ecosystem cannot support trust, you will probably embrace micromanagement.

We’re not being cheeky, Agile is not the only way to success or failure. But Agile is our only way.

Strengthen your resolve, make your gems community tested.

Mon, 18 Apr 2011 08:45:06 +1200

Strengthen your resolve, make your gems community tested.

How to name your gems

Fri, 15 Apr 2011 08:20:17 +1200

How to name your gems:

Why is it so hard to find ruby conventions? It’s the biggest aspect of the community, isn’t it?

Read the post

Community support and IRC (introducing SQLRecord)

Tue, 12 Apr 2011 08:22:40 +1200

A lot of my life has been spent on IRC. I got really sick of it. I got tired of the assumptions made by people meeting “anonymous” people for the first time. I include myself here, it seemed inevitable that I’d jump to conclusions without hearing someone out, and in turn made them sick of IRC too.

However, in a recent expedition into making my first clean-coded, well thought out Ruby Gem, I turned to IRC for help.

What I got was much more than I asked for, and it was all awesome-sauce.

The Idea

We use ActiveRecord::Base.connection.execute occasionally to run really fast read-only queries. Mostly for Dataviz.

I don’t like it. You get a row of string-keyed string-valued hashes back from the database. All that knowledge about the schema and how to handle differently typed columns that ActiveRecord gives us, gone.

Our views and view-helpers were littered with new idioms (bad habbits?) - the “Dealing with direct sql results” idioms.

Not only that, but the SQL queries were in controllers! Ick.

Enter SQLRecord

My first cut of this gem is SQLRecord v 0.1.0

It was my first ever DSL in Ruby, and I thought, quite idiomattic.

Time to doc.

So I started documenting. It was annoying me that my Yard Index was showing a module ClassMethods rather than showing them as Class Methods of the module that used the include-to-extend idiom.

So I went to #yard at irc.freenode.net channel to ask about indicating that this module’s methods belonged to another. Loren Segal was there and told me there wasn’t any way of munging the docs…

Extending themselves to the community.

Here’s the beginning of that discussion:

[08:50] Is there a trick in yard to make Module docs (like ClassMethods) look like those of the parent Module?
[08:51] <@lsegal> you mean like get ClassMethods to be interpreted as a set of class methods? Unfortunately not really
[08:52] yah thats what i meant
[08:53] http://yehudakatz.com/2009/11/12/better-ruby-idioms/ I’m going to re-read this until i get it.
[08:54] <@lsegal> indeed, that’s a good one. I’m not too fond of ClassMethods either
[08:55] <@lsegal> poor docs being one reason why
[08:56] <@lsegal> ClassMethods usually translates to “i have a poorly named mixin”

Yehuda’s post was haunting me but I wasn’t understanding it.

For the next 2 hours, off and on, Loren gave me a code review that changed my world view.

I would say that he improved Ruby by improving one passionate developers view of Ruby.

I now believed that good OO Principles were entirely practicable within this magical wonderland language called Ruby, where all ropes are long and could hang you, your family, and your-pit bull, without breaking a sweat.

Now I had a new perspective, a better Gem and I was pretty sure I was coding what I needed, without over-cooking it.

But wait, there’s more!

So one thing that happened as I re-factored, was a mistaken version bump into the 1.0s. Not where I meant to be. I trotted off to #rubygems at irc.freenode.net.

I got an answer about using gem ‘yank’ to remove a gem but then:

<@drbrain> you should not be embarrassed by releasing early and often

Ok then. I broke semantic versioning but I was hitting it hard and “showing my working”. Math education really does have value!

A little later, out of the blue, and not related to my versioning problem, but the code itself, someone said:

doesn’t AR::Base.find_by_sql solve this?

Ok! Here we go, the IRC I know and hate. Someones about to tell me I’m doing it wrong without background information…

Well no not really. Erik Hollensbe, as it turns out, had an abiding interest in what I was doing and made me argue the approach I was using. Moar gravy for my awesome-sauce.

That’s it. Thankyou to the community for being open minded, passionate and brilliant. I’ve had a very good week.

Ruby DSL post that answers (my) age old (2 days in reality) question

Wed, 23 Mar 2011 08:26:00 +1300

Ruby DSL post that answers (my) age old (2 days in reality) question:

Ruby DSL blocks need access to DSL methods. But which scoping to use?

Farm.new do 
  animal :kitten
end

Farm.new do |farm|
  farm.animal :kitten
end

TL;DR? You can support both!

Go read Rubylove’s article

New Flex Monkey! (Reloaded)

Tue, 01 Mar 2011 09:07:23 +1300

New Flex Monkey! (Reloaded)

Position Vacant - Rails Focused Technical Lead Role

Fri, 25 Feb 2011 13:21:00 +1300

Visfleet is looking for a certain someone to join our Agile team to develop our world class product.

Warning, bullet points follow.

That someone:

Has a love affair with RubyOnRails that they’re not ashamed to confess to.
Is looking for a senior role where they can help guide the architecture and vision of the product.
Enjoys multi-disciplinary work, like say, getting involved in Flex and Mobile development.
Is all about the Agile.
Wants to release often.
Wants to focus on quality code.
Likes to see users truly enjoy working with their product.
Can work in our Parnell Office, Auckland, New Zealand. (We will help with work/residency Visa’s for the right applicant)
Loves to mentor and be mentored.

The team:

Love RubyOnRails and Flex.
Enjoy Multi-disciplinary work.
Are all about Agile.
Come from diverse backgrounds, and love it.
Are proud of what they achieve, each and every release. And they release often!
Consists of 7 developers and 1 tester.
Wants to stay small and focused.

Learn more on this blog, our business blog, and our staff page

Also see our Kanban Board

The product:

Is the worlds best dispatch software.
Is web deployed, with clients for iPhone and Android.
Is simple and easy to use (honestly, that’s not hyperbole)
Solves real problems for a real demographic.
Is deployed in the cloud.

Learn more…

Visfleet:

Located in Parnell, Auckland.
Expanding into Australia and the USA this year.
A team of about 20.
Has a management and executive team that value continuous delivery and clean code! (Seriously OMG right?)
The business IS the team.

Want to know more, visit our web site

Want to apply? Contact us on jobs@visfleet.com

Extract Responsibility Refactoring.

Mon, 21 Feb 2011 08:36:05 +1300

In Martin Fowler’s “Refactoring” he introduces the “Extract Class” refactoring. I love this refactoring pattern and I use it all the time.

This refactoring is (unless im sorely mistaken) the most important one for the SRP.

Because of this intimacy with the SRP, I think there is an umbrella refactoring, called “Extract Responsibility” with two concrete methods for achieving it:

Extract Component (formerly Extract Class)
Extract Process (sometimes “Form Template Method”).

Extract Responsibility

You have one class responsible for the work that should be done by two.

Decide if the extra responsibility is encapsulated as a Component (Has-A) or a Process (IoC)

Extract Component

You have one class with an additional responsibility that exhibits compositional behaviour

Create a new class and move the relevant fields and methods from the old class into the new class (lifted directly from Extract Class)

The new class is a component if all it takes to make the refactoring, is to move methods. In my experience you are ‘Extracting A Component’ if the original classes’ data easily fits into a “Has-A” relationship.

Extract Process

You have two methods in subclasses that perform similar steps in the same order, yet the steps are different. (lifted directly from “Form Template Method”)

Create a new class, add process hooks in the new class and use those to call on the original classes actions.

OK so here is the crux of the matter. There are classes that still have too much responsibility, but it’s not in a ‘Has-A’ relationship. These classes have a ‘process’. These classes often present themselves in sets. Usually you will find two classes doing the exact same thing with moderately different behaviour.

The most suitable term for this extraction is “Inversion of Control”. Please don’t think I mean DI. DI, especially automated DI, is “Orthogonal Control” in my mind (topic of another post I must write).

The most common way I’ve seen of inverting control for a class or set of classes is the Form Template Method Refactoring. There are probably quite a few other methods for achieving IoC, including utilizing annotations.

The one I prefer is the Fluent Interface, and a beautiful example of IoC in fluent interfaces is Shaun Smith’s Promise Class.

In general I prefer Fluent Interfaces over Template Methods because they turn an ‘Is-a’ into a ‘Has-a’, providing far less coupling, and allowing for more than one ‘Process’ to be utilized by any given class.

This actually makes the new Fluent class a “has-a” relationship, so how does this differ from ‘Extract Component’? - You are not extracting data, you are extracting common behavior.

There is one downside to Fluent Interfaces: Language support.

In languages like Actionscript 3, you cannot delegate methods with static typing. This means that the callbacks you give your fluent interface are not compile time checked. In my next ‘Actionscript 4’ article I’ll talk more about static typed delegates and how much I think we need them in the language.

Finally

My apologies that my writing is not succinct. Writing is a craft I need to take more time to master. So please, feedback, opinions and constructive criticism!

Musings on AS4 - Part 1, Safe Navigation, Safe Exclusion

Sat, 05 Feb 2011 02:01:00 +1300

So I had surgery 2 nights ago. Routine Gall bladder thing. But the pain killers, namely morphine, keep me awake, contrary to their typical side effects. This left me up all night, in a hospital room, with such a calm mind and strange thoughts, that my desires for Actionscript began to crystalise.

These are meant to be idea’s to argue over, so please do comment.

Safe Navigation

Groovy’s Safe Navigation Operator is pretty straight forward:

var a:String = b?.c?.e

If b evaluates to null, a is null. Same for c.

It’s wonderful. I really don’t think I need to use Null Objects as often as I do.

Safe Exclusion

“Alan Kay’s meaning of OOP” and ObjC’s message passing got me thinking about thorough bi-directional decoupling. In the vWork application code, we have a considerable number of modules, which use a notifier bus (Robotlegs Modular context) to pass messages between modules. To properly decouple ‘Module A’ from ‘Module B’, I ended up with something like:

module.a.events.IRaiseThisEventOnTheBus
module.b.events.IExpectThisEventToBeRaised

or to be more concrete:

module.map.workerSelectedEvent
module.workerManager.selectWorkerEvent

and then I have a ‘master’ module manage the coupling. It listens for ‘workerSelectedEvent’ and fires the selectWorkerEvent. Now neither module has an import from the other…

The glue module still couples.

And this is the rub. My master module (usually the application boot module) has knowledge (read: imports) of both modules. Thats not a truly decoupled program.

Dynamic events

So the obvious way to get true decoupling is to use untyped messages. Like ruby, or ObjC might do. It works because a module can dissapear, and the other ‘dependent’ module is just listening for a magic string or symbol that never arrives.

I don’t like this approach, because I like type-safety.

Type-Safe events can be missing

My solution is to allow namespaces and classes to be missing. A kind of null-safety if you will. I can only describe it in code:

Describe an event class:

package module.map.events {

  import flash.events.*  

  public class WorkerSelectedEvent extends Event {
     ... event boilerplate ...
     public function get payload():TypeSafeThing {
       return _payload;
     }
  } 
}

And ‘Maybe’ consume it:

package module.workerManager.config {

  use module.map.events.WorkerSelectedEvent;
  use module.map.TypeSafeThing; 

  public class Config {
    ... stuff ...
    public function configWorkerListener() {
      if (WorkerSelectedEvent is _UndefinedClass)
        return;

      bus.addEventListener(WorkerSelectedEvent.SELECTED, selectedHandler);
    }
  } 
}

Where ‘use’ is defined instead of ‘import’, the compiler will find the Class, but if it cannot, it will replace it with an instance of _UndefinedClass, which has no methods or behaviour, it’s just a marker.

I would quickly replace EventDispatchers with something like Rob Penner’s signals (although I want to see c# style delegates, which I’ll cover in part 2). A signal/delegate message passing system could happily accept an _UndefinedDelegate and make most of this decoupling transparent.

I suspect ‘use’ would be the defacto when specifying message classes/delegates.

The Meaning Of Object Oriented

Tue, 25 Jan 2011 06:50:06 +1300

The Meaning Of Object Oriented

Dominic Graefen introduces a Flex/Flash Buildr Extension

Mon, 24 Jan 2011 12:29:00 +1300

Dominic Graefen introduces a Flex/Flash Buildr Extension :

Dominic Graefen (@devboy_org) introduces a Flex/Flash extension for Buildr. I recommend Buildr over Maven or other declarative build/dependency systems. Give it a go :)

Robotlegs Bootstrap Actor

Tue, 18 Jan 2011 09:05:00 +1300

I’m sharing the following Bootstrap Actor class, which simplifies bootstrap sequencing in Robotlegs.

I figure it has some value because Stray, who has a fairly similar programming ethos to me, see’s some merit in it.

Usage first.

Trigger the bootstrap in your context

override public function startup():void {
    commandMap.mapEvent(ContextEvent.STARTUP_COMPLETE, BootstrapCommand, ContextEvent);
    super.startup();
}

Which calls the BootstrapCommand

import org.robotlegs.mvcs.Command;

public class BootstrapCommand extends Command {

    override public function execute():void {
        injector.mapSingleton(ConfigurationSequence);
        injector.getInstance(ConfigurationSequence).step();
    }

}

Then implement the sequence

public class ConfigurationSequence extends AbstractSequencer {

    override protected function configure():void {
        addStep(ConfigureWorkersModelCommand);
        addStep(ConfigureScalesModelCommand);

        ... yadda yadda ... 

        addStep(ConfigureJobDraggingModel);
    }

}

What happens is that the line in the bootstrap

injector.getInstance(ConfigurationSequence).step();

instances the Sequencer and tells it to run the next step, which in this case, is the first one.

Each command added with ‘addStep’ is added as a command mapping which responds to a SequenceStepEvent with a named type. This is not conventional behavior for an event, but it works really well in this context.

Finally, a sequenced command looks a bit like this:

public class ConfigureScheduleHeaderViewCommand extends Command {

    [Inject]
    public var event:SequenceStepEvent;

    override public function execute():void {
        mediatorMap.mapView(TimelineView, TimelineMediator);
        ... yadda yadda ...

        event.step();
    }
}

The event.step causes the next item to be run.

Source Code

The sequencer gets the addStep() and configure() methods from AbstractSequencer.as.

You also need the SequenceStepEvent.as class

Options

Bootstrap command and context

You could merge BootstrapCommand into the context. I prefer to overdo SRP than underdo it.

Automatically step

Instead of specifying event.step() in each sequence command, you could modify AbstractSequencer#executeNextStep like this:

private function executeNextStep():void {
    var classFQN:String = steps.shift();
    var event:SequenceStepEvent = new SequenceStepEvent(classFQN, this);

    dispatch(event);

    step();
}

Have you seen our Kanban Camera?

Tue, 21 Dec 2010 07:17:41 +1300

Have you seen our Kanban Camera?:

Our kanbancam runs 24/7 (with archives) at http://www.kanbancam.com/

This is the view of our Kanban wall. To the right of frame you can see our information radiator showing our Hudson CI status.