shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Schofield" <>
Subject Re: [dialog] Using SCXML to describe Shale dialogs
Date Fri, 25 Aug 2006 23:15:23 GMT
I have few initial concerns after looking over the excellent
documentation and examples on the Commons SCXML site.

So far, my concerns are as follows:

1.) I'm not wild about having to run an XSL transform on dialogs
during compile time but the SCXML approach to configuring dialogs
seems to involve excessive XML if you're not using UML.  Don't get me
wrong.  Its a very cool concept but I'm not sure going from UML to
dialog config is the most important feature in a dialog solution.

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.

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.

I haven't made up my mind on SCXML - in fact I seem to be swinging
back and forth.  Even if we don't go with it right away, I think it
merits further study (and a place in our sandbox.)

I'm curious as to what others think.


On 8/24/06, Rahul Akolkar <> wrote:
> On 8/24/06, Rahul Akolkar <> wrote:
> <snip/>
> >
> > Yes, the UML notation on a transition is:
> >
> > event[guard_condition]
> >
> > Simply put, the states that have faces.outcome listed as the event are
> > view states (wait for the postback "event") and the others are action
> > states.
> >
> <snap/>
> Sorry, the above should read:
> ...  the states that have faces.outcome listed as the event *on
> outbound transitions* are view states ...
> -Rahul
> > You can skip the event, the guard condition or both on a transition.
> > Eventless transitions get evaluated as soon as executable content
> > "onentry" for that state is done. The symbol and text label under the
> > "checkCookie" state label implies execute that method binding
> > expression on entering the state (which gives us the logical outcome
> > to choose the outbound transition).
> >
> > -Rahul
> >
> >

View raw message