My main point in suggesting we "scrap" subdialogs is that we stop treating them in the manner that Rahul is describing (as GOSUB approach.) If we eliminate this stack approach to the context then everyone is happier and I think we'd all be in 100% agreement.
The question is the best approach to do that. The idea of injecting the state was just off the top of my head. The SCXML sounds better but I don't know anything about SCXML and haven't read Rahul's post on that yet. Sean On 8/24/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
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 > >
