shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [dialog] Using SCXML to describe Shale dialogs
Date Sat, 26 Aug 2006 00:32:54 GMT
On 8/25/06, Craig McClanahan <craigmcc@apache.org> wrote:
> On 8/25/06, Sean Schofield <sean.schofield@gmail.com> 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
>

Mime
View raw message