This project is read-only.

A couple of questions...

Jul 11, 2008 at 8:57 AM
Great work -- thanks!

Is there a way to define hierarchical states?  And concurrent states?  Any plans to support these in the future?

And -- do you know if the current implementation works on the Compact Framework?

  Vikram
Coordinator
Jul 11, 2008 at 6:22 PM
Sorry, I don't know if this works on CF - you'd have to try it out :) As for hierarchical states, there is no direct facility for that now in a single state machine definition, but it is easily accomplished using child workflows. There have been a few posts about this in the forum already, I suggest you take a peek. Currently you would need to define a custom task to start your child workflow, but I do intend to make this part of the framework in the future. As for concurrent states, i.e. not in the context of a hierarchical state machine, I haven't considered that. Can you share a use case?

BeauGeek wrote:
Great work -- thanks!

Is there a way to define hierarchical states?  And concurrent states?  Any plans to support these in the future?

And -- do you know if the current implementation works on the Compact Framework?

  Vikram



Jul 12, 2008 at 7:46 AM
If I'm understanding child workflows correctly, you spawn off a completely new workflow that then has no connection to the state that started it.  I was thinking of hierarchical states in the sense of nested states in which a child state that is currently active, on receiving an event it doesn't know how to handle, would pass the event on to its parent, which may indeed trigger a transition from that larger state.  This way, you can abstract out common behaviour to the parent state, thus avoiding a lot of duplication.  Miro Samek's got a whole lot about this in his book and on his website for his "Quantum Leaps" framework.

As for concurrent states -- it's late, so the only example which is coming to mind is something I saw online a couple of days ago -- in a Flash video player, "Play" and "Pause" states would be independent of "Full Screen" and "Not Full Screen" states, but would run concurrently.  Of course you could have two independent state machines to handle this, but it'd make more sense to have parallel regions in one state machine, running concurrently but independent of each other.

  Vikram
Coordinator
Jul 14, 2008 at 6:11 PM
1. Oh - THAT kind of hierarchical state machine :) Like Windows Workflow has (although that feature doesn't always work in WF, sadly). Yes, I will hopefully add such a feature in the future. The workaround, of course, is to add a listener for the "parent" event to each "child" state, which is a pain in the butt and exposes the system to silly bugs. The state machines we use in our production systems are often hierarchical, and we've applied the workaround described, and it definitely isn't ideal. I don't know when such support will emerge, because in addition to implementing support in the core library, the DSL will need a special syntax for defining hierarchical state machines, but I'll be re-writing the DSL using Irony.net as an alternative to Boo soon, so maybe I'll take the opportunity at that time. Thanks for the feedback.

2. I would really just use two state machines here. You could easily wrap multiple state machines in a parent class to make them appear as one, but if the "concurrent' state machines don't interact meaningfully with one another, I don't think the feature would be worth adding the complexity to the framework required to manage it. BUT - that judgement is based only on the use case you gave, there may be other use cases for concurrent states that are more compelling, but I just don't know what they might be :)

BeauGeek wrote:
If I'm understanding child workflows correctly, you spawn off a completely new workflow that then has no connection to the state that started it.  I was thinking of hierarchical states in the sense of nested states in which a child state that is currently active, on receiving an event it doesn't know how to handle, would pass the event on to its parent, which may indeed trigger a transition from that larger state.  This way, you can abstract out common behaviour to the parent state, thus avoiding a lot of duplication.  Miro Samek's got a whole lot about this in his book and on his website for his "Quantum Leaps" framework.

As for concurrent states -- it's late, so the only example which is coming to mind is something I saw online a couple of days ago -- in a Flash video player, "Play" and "Pause" states would be independent of "Full Screen" and "Not Full Screen" states, but would run concurrently.  Of course you could have two independent state machines to handle this, but it'd make more sense to have parallel regions in one state machine, running concurrently but independent of each other.

  Vikram