shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [dialog] Submachines, Contexts and Shale subdialogs (was Re: Get rid of subdialogs)
Date Thu, 24 Aug 2006 22:49:02 GMT
On 8/24/06, Craig McClanahan <craigmcc@apache.org> wrote:
> On 8/24/06, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
> >
> > [snip]
> > 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".
>
>
> So, to see if I'm getting it yet, are the following statements an accurate
> representation of what you're describing?
>
> * SCXML achieves reuse by essentially "inlining" a previously
>   configured set of descriptions into the current one; and
>
> * When that happens, there is only one "context" instead of the
>   stack that Shale Dialog currently creates when you use
>   a subdialog.
>
<snip/>

Correct (one root context, thats a quibble about hierachial / per
state contexts -- only applicable if each state can have its own
"namespace" -- IIRC, not in the current Shale dialog notation).

The end result is one state machine. Thereby, I can "decorate" the
subdialog with a transition that points to a state in the parent
dialog (often the thing that hampers reuse is the inability to
incorporate the subdialog effectively because it cannot "see" the
view/action states in the parent dialog if its a completely new state
machine).

-Rahul


> -Rahul
> >
>
>
> Craig
>
>

Mime
View raw message