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:
Each of the above nodes can contain either of these children:
Here is an example:
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.