Finally I’ve done what I should have done ages ago, instead of writing layers (and layers) of abstraction over the pureMVC statemachine utility, I have just rewritten it.

The over heads of the Domino code was ridiculous, and besides there are other frameworks out there, Robotlegs in particular.

So what I have done is to free it from any:

  • framework dependencies,
  • comms bus dependencies (events, signals, notifications),
  • and data dependencies (for declaring the FSM).

The source is at AS3StateMachine on github, and I have registered for all related stuff.

My favourite is the Signal StateMachine for Robotlegs


OK, so after some discussion with Nils Millahn I have cut down the functionality for my first release of Domino.

Domino will build and inject the StateMachine and add these additional functionalities:

    1) the ability to define custom States in the XML markup
    2) two additional notifications:
  • cancelled called when a state transition is cancelled
  • teardown called when the state has changed successfully, but before the entered notification is send for the next state.
    • 3) the ability to declare a command in the XML to be executed at each stage of the state transition cycle.
      4) the ability to declare state specific notifications in the XML to be send at each stage of the state transition cycle.

    the XML:


    So at the moment I’ve given it to a few people to have a look at it to give feedback, and when I’m happy will upload it to my google.code site.

    Oh and please feel free to leave your own suggestions :)

    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.
    Continue reading

    Domino: the Concept

    I’ve been attempting to build a real world application using Domino, just to see how it works. The example is a FlickBook application, and Domino is proving quite easy to use, and is doing what I originally intended, which was to help me organise and visualise my commands better.

    I’m not going to show any demos or code here, but I thought I’d explain the concept. To tell the truth I’m not sure if this is just an interesting experiment, or has any serious value, so I would like your opinion.

    Some Definitions

    Link: represents an instance of a command which may have some metadata injected into it.

    Chain: a list of links, executed top down. A chain can be public (invokable from the main framework) or private (accessible only from inside domino).

    ChainSet: a collection of chains that declares a list of states in which the member chains are active.

    Link Types

    [kml_flashembed movie=”” height=”255″ width=”470″ /]

    overrides a method with the signiture:

    protected function process ( notification:INotification ): void

    Changes something within with pureMVC frame work, and/or the incoming notification. Once completed, the next link in the chain is executed.

    overrides a method with the signiture:

    protected function evaluate( notification:INotification ): Boolean

    Tests a condition within the pureMVC framework and/or incoming notification, and returns a Boolean value.
    false: the next link in the chain is executed.
    true: the execution thread is redirected to the link indicated in its metadata. This can be any link in the current chain, or the first link in a different chain (see also ReturnLink).

    overrides a method with the signiture:

    protected function prepare( notification:INotification ): void

    The execution thread is redirected to the chain indicated in its metadata. The prepare method hook allows the outgoing notification to be changed before redirection (see also ReturnLink and Notification Scope).

    final class:
    Returns the thread back to its referring chain.

    final class:
    Ends the process and notifies the rest of the pureMVC framework.

    Notification Scope
    Each Chain maintains its own notification. If the thread is redirected to another chain via an EvaluationLink or a GosubLink, then the original notification is restored if and when it is returned to that chain.

    Consider this diagram:
    [kml_flashembed movie=”” height=”775″ width=”470″ /]
    We have three ChainSets, one active in the “init” state, another active in the “exit” state, and the third active in both.
    The initiation and exit ChainSets have public chains that are invoked on entry into their declared states. The “utils” set’s chains are all private, thus can be accessed only by referral from another active chain.

    1) The Init State is entered, and the chain EnterInitState is invoked:

  • CreateActorList (a GosubLink) is executed. This retrieves an Array of class paths from the ConfigurationProxy, adds it to its notification and redirects the thread to the createActor chain (see 2).
  • when the thread returns to the chain, the TerminationLink is executed which ends the process, and sends a TERMINATION notification to the rest of the framework
  • 2) The createActor chain recieves an Array as the notification body:

  • its first link ShiftArray (a GosubLink), shifts an element off the Array, and redirects it (see 3)
  • the second element ArrayLenZero (an EvaluateLink) checks the length of the Array, if it is > 0 it loops back to ShiftArray, otherwise it continues to
  • the final ReturnLink, which returns the thread back to its referring chain
  • 3) the createNotifier chain receives a class path (String) as its notification body

  • the CreateNotifier link (a SynchProcessLink) creates a class instance from the class path, and adds it to the notification body
  • then the RegisterNotifier link (a SynchProcessLink) checks the notification body type, and registers it with the facade accordingly
  • the final ReturnLink returns the thread back to its referring chain
  • The overall effect is to create and register all the application’s Mediators and Proxies from a list in the config when the application enters its init state.

    I think thats all fairly simple to understand… I’ve thought very much along the lines of Chain of Responsibility. If an element does not know how to deal with something, it passes it on. I also have an error handling system prepared and implemented, but not yet tested.

    Should I proceed, the next step is to take the XML and create a tool that visualises it (like the diagrams above which were, alas, laid out by hand).

    I’d love to know what people think:
    An interesting experiment or something with real-world value.


    the xml this visualises is here


    Well, I’ve got the Domino core classes working on some simple test examples (without any error handling classes).

    I want to create a more real world example before I show anything, and in the mean time, I’ll write down a few notes on how it all works.

    brain freeze

    I have been working lots on my Domino project, to-ing and fro-ing about its complexity and its usefulness. Been bouncing ideas of Pedr Brown, which has been good (he didn’t think it was a useless idea, just that I was going about it from the arse end).

    So I’m almost there with the core classes, and am working up a unit test to give it a twice over.

    These classes will provide the model and controller for the command chains. The next step (at Pedr’s suggestion) will be creating a visualisation tool for the model: basically drawing up a non-interactive flow diagram of the command processes, so you can see their relationships to eachother.

    The final step, if all goes well, will be to create an interactive visualisation tool… which will be the biggy.

    My main headache has been trying to hook it up to the StateMachine utility, because of its Synchronous nature. But lets tackle that problem when we get there, mmm?

    here’s to it :)

    Domino effect

    Have had a bit more time of my hands at the moment, so I having been spending more time with my son, and have had renewed enthusiasm for my Domino project…

    The new pureMVC StateMachine Utility has enabled my to simplify my ideas again.

    Be assured, I shall be posting my ideas here soon… as long as I don’t bog myself down in detail again.

    Grabbing the low hanging fruit

    I’ve just come out of Aral Balkan’s FOTB talk entitled as above, so I decided to take his advice – if you have an idea put it out there.

    Basically, this is an idea I’ve been working on and humming and ahhing over, but now I’m going to tell you all about it, so that I don’t have the excuse not to do it.

    Its a big idea, but I’m going to start it off small.

    Anybody who reads my blog (LOL that’ll be [email protected], plus one or two who have wondered off the main track into strange waters) will know that I’ve been playing with pureMVC for a while now and one of the main problems that I have with managing pureMVC projects is that the controller / observer actors do so good a job at decoupling themselves.

    This means that I have a real problem organising and managing my commands and notifications because I can’t find them easily. This is doubled if you are using a state machine to rewire all the commands dependant on state.

    wouldn’t it be fantastic if you could fire off one notification that would
    1) cause a whole string of commands to be executed in order, whether they are
    2) synchronous, or
    3) asynchronous,
    4) make decisions along the way, including
    5) user defined ones (ie alert boxes),
    6) carrying with it data from the invoker,
    7) and then spit out the result with another notification to be picked up by any interested parties.

    well, I think it would.

    What I’m taking about is encapsulating the flow of commands into a single data source (XML,JSON, whatever).

    Once that has been done, we can

    1) not only load it into your application to tell it how to wire itself up properly,
    2) rewire your application, without recompiling
    3) rewire your application at runtime depending on state
    4) if the command classes are compiled into a runtime swc or swf you can also rewrite your commands without without recompiling your whole app
    5) you can use other programmes to look at it, in far prettier ways than the native data format (XML ain’t that human readable)
    6) you can edit it and re-organise it
    7) you can even use it to create stub code.

    Now, I’ve already started down this path, I’ve done a quick prototype of a data driven command sequencer, and I’m just starting to rebuild it as a more solid framework, though I really don’t have anything to show at the moment. But I shall keep you all posted here. It would be great to get some feed back as to whether the idea is good or not, maybe some one has already, or is in the process of doing this themselves.

    But most of all, I’m writing this to encourage me to actually do it.