Domino rides again

Strange how things come full circle.

Last year I was trying to manage the flow of pureMVC commands in my applications. Two things came out of this, the StateMachine utility, and an idea that I christened Domino. Well, Domino went a bit strange on me, and eventually I let it fallow for a bit while I worked on the FSMVisualiser.

I’ve been manically working on several projects this year, and as I was commenting a utility that had been evolving throughout this time, I realised that with a tweek here and there I could create a layer of abstraction over the StateMachine utility in a simple and (I hope) elegant way. It would fulfill the original purpose of Domino without getting really complicated in the process. Basically it extends the StateMachine markup XML so that it also defines the relationships between pureMVC actors within each state.

This month I’ve been able to do a bit more work on the FSMVisualiser, and am incorporating my Domino utility into it as a proof of concept.

This is how the current StateMachine is defined through XML:

public static const STATE_DISPLAYING:String = 'state/displaying';
public static const STATE_EDITING:String = 'state/editing';
public static const ACTION_EDIT:String = 'action/edit';
public static const ACTION_DISPLAY:String = 'action/display';

public static var fsm:XML =


Domino includes six optional nodes in addition to the transition with in the state node:


These describe stages in the StateMachine’s transition cycle, or interests in specific notifications. Lets have a closer look at them:

  • entered: this describes an interest in the state-specific changed notification for the state. (NB I changed the name as I felt it more intuitive in the context)
  • entering.guard: this describes an interest in the state-specific entering notification.
  • exiting.guard: this describes an interest in the state-specific exiting notification
  • cancelled: this describes an interest in the general cancelled notification of a state transition (transitions should be cancelled from either the entering or the exiting guard).
  • tear.down: executed when a transition has been successful, and the state has changed, but before the entered ‘interest’ has been fired. (NB this is not triggered by a notification, but by the removal of the DominoMediator from the framework)
  • interest: this describes an interest in any notification (defined in the @notename). If a notification of that name is send within the state, the instructions it contains will be executed
  • —————————————————————-
    Each of the above nodes can contain either of these children:

  • send: this sends a notification, with the body and type of the incoming notification and the name defined in the @notename. An optional @type can be injected into the forwarded notification which will overwrite the current type of the notification
  • execute: this executes the ICommand defined in the @classpath. An option @type can be injected into the forwarded notification which will overwrite the current type of the notification
  • —————————————————————
    Here is an example:

  • The state is entered,
  • AssembleModelCmd Command is executed,
  • AssembleViewCmd Command is executed,
  • CreateStateFormMediator sends its READY notification with its view as the body,
  • this is picked up by the interest (CreateStateFormMediator.READY), and
  • redirected to FSMVizMediator’s ADD_TO_EDIT_PANE interest, which adds it to its view’s display list,
  • the SendStateActionCmd is executed with the type as ACTION_ASSEMBLED
  • the state transitions to STATE_AQUISITION.
  • You will also notice that each state’s @changed, @entering and @exiting do not need to be defined, as Domino will take care of that for you.

    I’m not releasing any of the code yet until the FSMVisualiser is finished (I hope by the End of November), but I would be very glad of any thoughts or feed back on this.

    cheers :)

    5 thoughts on “Domino rides again

    1. This looks awesome, the bigger “+” for me is the binding of the entered state to the command, I had a lot of duplicates with states that looked like notifications for the command/state binding that that would alieve a lot of the extra plumbing.

    2. Seems really interesting. I hope that we can use notename as well as classpath in the execute node, it will help loose coupling in the rest of the application.

    3. @ tek: well, you couldn’t use @notename in an execute tag, if you wanted to trigger another notification you would use a send tag with @notename

      Is that what you mean, or am I missing something?

    4. pedr brown has just given me some good advice, which is to allow separation from the StateMachine.
      In that way its only dependency is the pureMVC frame work. The separation is already there, I just need to formalise it.


    5. Pingback: Anonymous

    Leave a Reply

    Your email address will not be published. Required fields are marked *