shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [dialog] Using SCXML to describe Shale dialogs
Date Sat, 26 Aug 2006 23:24:37 GMT
On 8/26/06, Sean Schofield <> wrote:
> > 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).
> Yes I agree with this.  Would there be a way to convert the dialogs
> from XML using a listener.  I would have to rely on a maven build
> executing before I could deploy something through an IDE.  I'm not a
> big fan of that sort of thing.

That's certainly possible, but which IDE are you using?  The Mevenide plugin
for NetBeans (at least) lets you run Maven builds from inside the IDE as
well, so customizing the build would hav worked fine for me.

> > 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.
> Lets get started with some experiments then.  There is an area in the
> sandbox for dialogs.  Maybe we could try two approaches?  One sandbox
> area for an SCXML implementation and one for an improved version of
> the current implementation.

I'm taking a crack at the former, also looking to see if we can abstract out
what the rest of Shale has to know about hte actual dialog implementation,
and provide for plugagbility.  Hope to have something checked in tomorrow

> Craig
> Sean


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