shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [dialog] Using SCXML to describe Shale dialogs
Date Fri, 25 Aug 2006 23:51:47 GMT
On 8/25/06, Sean Schofield <sean.schofield@gmail.com> wrote:
>
> 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.


Do you agree that we should continue to support a simplified configuration
format like the current dialog-config style?  Besides backwards
compatibility (which is an issue), I'm thinking we want to offer an
alternative that is easier for hand coders.  The need goes down for this
when there are GUI tools to assist you in setting it up (or a tool that
translates a real UML state diagram).

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.

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 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.   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


On 8/24/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> > On 8/24/06, Rahul Akolkar <rahul.akolkar@gmail.com> 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
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message