shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject [dialog] Using SCXML to describe Shale dialogs
Date Thu, 24 Aug 2006 21:57:21 GMT
I'd like Shale to support both the current dialog notation and SCXML
as stated here [1], and both can use the same underlying engine. The
current dialog notation by virtue of being the incumbent, and SCXML
because:

 * SCXML is a well-defined distillation of all variants of state
machine theory. Its roots are with classical state chart theory (Harel
state tables) and it aligns with latest UML standards (UML 2.0). It
brings to the table most essential features of generic state machines.
Shale dialogs currently provide a subset of those features.

 * As we look at prior art, we see different XML vocabularies doing
the same (similar) things. Shale dialogs, SWF, Seam PageFlows, others.
In an ideal world, we strive towards standardization (we like JSF :-)
-- and the W3C has traditionally worked with markup languages.

 * The SCXML vision is more of a client-side statement, and agreed,
its not obvious at this point. Pending success in browser adoption, it
is perceived to drive "behavior" on graphical and speech browsers (add
alignment with multi-modal standards as another plus) -- the advantage
then is being able to draw a circle around part of my state machine
diagram and consume that bit at will on either the client or server;
should be a joy for MDD and programming model enthusiasts alike.

 * The tooling aspect gets an immediate boost by virtue of UML2
alignment, there are plugins (none open-source yet) that can transform
state chart diagrams into SCXML documents. That means if you really
dislike XML, you'd still be OK ;-)

Thats important, but somewhat abstract. Concretely:

 * We know its doable [2], I've been using it (on a slightly dated
distro that I'll be happy to bring upto date).

 * It satisfies the relevant requirements from a notation perspective
as outlined on the DialogManagerFeature wiki page [3]. From the
mandatory requirements, I see 1 through 7 as more of notation
requirements, and hence, particularly relevant here.

 * Everything that Commons SCXML needs (Digester, JCL, EL) is already
used by Shale dialogs (or provided by the container). No new
transitive depedencies.

 * Commons SCXML has been released. Earlier, sandbox code was simply a
showstopper, IMO.

 * It will be explicit developer choice. The SCXML NavigationHandler
that gets plugged into Shale dialogs (so you can use SCXML documents
to describe Shale dialogs) can only be configured in the application
(or otherwise) faces-config. There is no way to mistakenly turn on
that switch, so backwards compatibility is fully retained. New
applications, OTOH, get a choice.

-Rahul

[1] http://marc.theaimsgroup.com/?l=struts-dev&m=112900158004770&w=2
[2] http://jakarta.apache.org/commons/scxml/usecases/scxml-in-shale-dialogs.html
[3] http://wiki.apache.org/shale/DialogManagerFeature

Mime
View raw message