A friend of mine (lets call him John) wanted to create a theatre company and produce devised pieces based on clowning techniques (when I say clown, think Homer Simson, not Krusty). He succeeded in his grant applications, got a very talented bunch of performers together, the best director in the field, and started devising.
It was all going really well, except for one thing.
Recently I’ve been feeling overwhelmed and underfulfilled in my work.
There is just TOO much to learn: the geek front-line is running away with itself, and I am feeling a little bit too old ever to catch up.
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:
- 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.
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 :)
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.
just put the FSMViz project on my google code page.
To grab from the svn use:
UPDATE: removed this demo due to it getting infected. Will upload a newer version once I have time to work on something
I have added some more functionality to the FSMViualisation.
Just a few notes:
1) I haven’t been able to add labels to the actions (arrows) yet (well, not prettily anyhow).
2) I have used the BundledEdgeRouter which makes those nice arrows. The problem with this is that any arrow that connects the same two nodes will lie on the same line.
3) at the moment, to update the diagram, I am having to edit my VOs, parse them into a Flare Data object, then construct a new Visualisation with it. It seems a bit expensive (not that affects the speed at all).
4) you can add States into a package. This does not affect any of the code that will eventually be exported, but does allow you to group the state together, and makes the diagram look far more appealing.
OK, have put together the first visualisation for a pureMVC StateMachine Utility markup tool.
The purposes of this tool are:
1) to make a state diagram for easier visualisation of the flow of your application
2) to create the FSMInjector class for your application, along with all the necessary constants, and the XML declaration.
The visualisation data is stored as a text file in JSON, along with all the metadata associated with each node and edge. This will be the file format for saving and retrieving work. There will also eventually be an export routine that will convert this format into the FSMInjector.
At the moment we just have the ability to visualise, not to edit. The next pieces of functionality I will be working on will be:
1) adding states.
2) deleting states.
3) adding edges (actions).
4) deleting edges.
[kml_flashembed movie=”http://www.revisual.co.uk/uploads/2009/may/fsm/demo1/demo1.swf” height=”400″ width=”470″ /]
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.
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.
[kml_flashembed movie=”http://www.revisual.co.uk/uploads/2009/jan/domino/domino_key.swf” 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).
Returns the thread back to its referring chain.
Ends the process and notifies the rest of the pureMVC framework.
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=”http://www.revisual.co.uk/uploads/2009/jan/domino/domino_diagram.swf” 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:
2) The createActor chain recieves an Array as the notification body:
3) the createNotifier chain receives a class path (String) as its notification body
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
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.
Well, finally my StateMachine utility is officially hosted on the pureMVC Manifold… download it here.
Its quite different than the original in a number of ways:
1) the utility conforms to the basic SCXML standard, and comes with a FSMInjector class that creates the StateMachine from an SCXML defined model.
2) the transitions from state to state are no longer purely linear; multiple legitimate target states can be defined within each state, so the transitions can be dynamically decided at run time.
3) the StateMachine class now only sends notifications, it doesn’t execute registered commands directly. This means that other actors (ie Mediators) can declare an interest in them.
4) transitions can be cancelled from the exiting phase.
When I’ve a little more time I shall write a more in depth tutorial. But for the moment, have a play, and see what you think…