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] Submachines, Contexts and Shale subdialogs (was Re: Get rid of subdialogs)
Date Thu, 24 Aug 2006 22:21:15 GMT
On 8/23/06, Sean Schofield <sean.schofield@gmail.com> wrote:
> I'm not quite convinced that <subdialog> is very useful as
> implemented.  I see the usefulness in stringing existing dialogs
> together but certain byproducts of subdialog are undesirable.  For
> instance, SHALE-153 which complains about how you can't easily access
> state information between a "parent" and "child" dialog.
>
> I've discussed this with Craig before and IIRC he doesn't agree with
> me on this but I can't see how having subdialogs as "black boxes" is
> very useful.  Maybe there are some use cases out there but it would
> seem to me that its much more common that you would want to share
> state across two dialogs.
>
<snip/>

I've quickly browsed the rest of the previous ("was") thread, and it
seems there is consensus to retain the subdialogs feature, but in
addition, I wanted to point out the need for subdialogs from a MDD
perspective and relate the particular discussion in SHALE-153 with
state machine theory.

Regarding the use and reuse of subdialogs:

 * Submachine states are a vital part of most state machine
"dialects". It stems from the simple fact that beyond "hello world"
examples, any application dialog is inherently too complex to fit in
one bite sized piece. UML modeling allows the addition of submachine
states in state machine diagrams (which open up into state machine
diagrams of their own) and standardized notations like SCXML allow to
"inline" another document in a state, i.e. use:

<state id="foo" src="foo.scxml" ...>
 ...
</state>

where foo.scxml is another state machine altogether. Subdialogs are,
therefore, an important concept to retain.

 * The intent of using subdialogs for reuse beyond basic CRUD
operations comes from the fact that it should be possible to use
subdialogs while "decorating" them in the parent dialog (i.e. adding
or overriding certain transitions or states). IIRC, Shale dialogs
allows some of this, just like SCXML?

Which brings us to the discussion about sharing "dialog data" as-in
SHALE-153, and this is where Shale subdialogs deviate from most
dialects of state chart theory, where submachine states are not
processed according to the stack-based GOSUB approach WRT state
contexts. A submachine state is meant to be "syntactic sugar" and
should not have any difference in (runtime) semantics as compared to
inlining the submachine into the parent state machine. And that tends
to blow away any concerns about sharing data / communicating across
parent-child (sub)dialogs.

i.e. if foo.scxml from the snippet above pointed to this degenerate machine:

<scxml initialstate="end">
 <state id="end" final="true" />
</scxml>

the original state above may be replaced by the following:

<state id="foo" ...>
 <initial>
  <transition target="end"/>
 </initial>

 <state id="end" final="true" />
 ...
</state>

for identical behavior. Commons SCXML will "crawl" to the src URL,
grab the state machine from foo.scxml, parse and incorporate it into
the parent state machine as the state holding the src attribute. The
"root context" of foo.scxml then becomes the context for the state
with id "foo".

-Rahul

Mime
View raw message