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] Get rid of subdialogs
Date Thu, 24 Aug 2006 21:12:30 GMT
On 8/24/06, Craig McClanahan <craigmcc@apache.org> wrote:
> On 8/24/06, David Geary <sabreware@gmail.com> wrote:
> >
> > 2006/8/24, Sean Schofield <sean.schofield@gmail.com>:
> >
> > > > I think the scope is useful, but I'm still not convinced the extra
> > > > complexity required to support easy access of ancestral data on the
> > > dialog
> > > > stack is worth the effort. It seems to me that you can easily handle
> > > > situations like this with setup actions that synthesize the right data
> > > and
> > > > make it available to the view via #{dialog.data}.
> > >
> > > So we abandon #{dialog.data} and leave it as an "exercise for the
> > > user" to supply their own mechanism for managing a "dialog scope"?  Is
> > > that what you're saying?
> >
> >
> > I'm not sure. I am somewhat uncomfortable adding new functionality when
> > there's already a valid mechanism in place, especially when such a change
> > requires considerable design changes. And in this case, we've got our
> > hands
> > full of things that must be fixed for a viable dialog implementation
> > that's
> > usable in production, such as supporting simultaneous dialogs. I'd rather
> > concentrate on those things first, hoping that the smaller issues, such as
> > this, will fall out in the design, if appropriate.
>
>
> I'm going to start my personal quest here by reviewing the context storage
> and instance disambiguation strategies of some of the "prior art" links.
> Because I need to look at it anyway, I'm going to start with Seam, and then
> post a summary onto the wiki page.  Anyone else fancy taking a look at how
> others do this sort of thing, and reporting back?
>
<snip/>

Some relevant bits on Commons SCXML:

 * Context storage -- Hierarchial contexts, each <state> has its own
context / datamodel / namespace. v0.5 works like blocks in a
procedural language, you can "see" variables in your ancestor states.
Datamodels can be declared declaratively, or one may procedurally
inject data into the documents root context. There will probably be
two enhancements soon:

   1. Latest Working Draft requires ability to refer to data in
non-ancestor context using the stateID.variable notation.

   2. Flat context option: There was a user request for that, can
probably be provided with a switch that collapses everything into one
document context.

 * Multiple instances of the same state machine -- Commons SCXML
clearly differentiates between the abstract model of a state machine
and a concrete executing instance thereof. Care has been taken to make
sure the model itself is stateless, and hence can be reused by as many
executor instances as possible (in other words -- parse once, execute
as many times).

 * Disambiguation strategies -- A suitable disambiguation strategy
should be employed by the "environment" in which Commons SCXML is
used. The strategy could simply be some key-based instance
identification.

There was some interest on the commons lists for using SCXML in SWF,
and I've been meaning to look at SWF, so I can volunteer for that as
well.

-Rahul



> Craig
>
> david
> >
> > >
> > > Sean

Mime
View raw message