On 8/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 8/25/06, Sean Schofield <[EMAIL PROTECTED]> wrote: >
<snip/>
2.) Each dialog needs its own SCXML file. In one extreme use case > where you have a ten step dialog and you want to have individual > single step dialogs for each of ten steps, you'd need 11 SCXML files. The states that represent your subdialog can be nested inside the state that represents each step, so they can all live in the same file. That only works if you don't need to resuse them, in which case a separate file (perhaps included via XML entities or something if you need the semantics of nested states) would seem like the way to go. 3.) Global transitions need to be configured in each of the SCXML > files (is that right?) While I realize these should be ideally coming > from the UML, the reality is a lot of people will not be using SC to > design their dialogs. If I'm understanding Section 3.3.1 of the spec right, nesting the states of your subdialogs would deal with this as well ... the transition out of a substate can use a target state that is defined by a parent -- essentially behaving like a global transition.
<snip/> Craig's responses for (2) and (3) are well-written. I was taking the extreme cases for what they were, without trying to suggest how one would rewrite them in SCXML for good leverage of that notation.
I'm definitely in favor of doing some experiments. My gut is that I'd rather focus on mapping a generic state machine to the web world than having to do that and maintain the state machine engine itself.
<snap/> IMO, the above line hits the nail on its head. -Rahul
In addition, an SCXML state engine has lots more power than the bare bones one that dialogs currently has. And things like the ability to use an EL expression on a "cond" (a guard condition on a transition) lets you express lots more complicated decisions without having to write any Java code. I'm curious as to what others think. Likewise. Sean Craig
