On 8/24/06, David Geary <[EMAIL PROTECTED]> wrote:
2006/8/24, Sean Schofield <[EMAIL PROTECTED]>:
> > 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?
Craig
david
> david
>
> Sean
> > > > david
> > >
> > > Sean
> > >
> >
> >
>
