On 8/24/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 8/24/06, Rahul Akolkar <[EMAIL PROTECTED]> 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
