Craig,
Maybe you can use the VariableResolver and PropertyResolver to return that
information to the user...
On 11/27/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 11/27/06, Enrique Medina Montenegro <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm trying to understand the way Shale 1.0.4-SNAPSHOT expects me to work
> with subdialogs. Let me explain it with an example.
>
> Suppose I start one dialog which refers to one screen in my application.
> Then I want to reuse the next screen (and the following ones) throughout
> my
> application, so I model these screens as a complete dialog, where I can
go
> from my original dialog using a subdialog. This works great, but then
when
> the subdialog is executed, I cannot get the parent dialog data. And it
is
> there, because while debugging I can see in my variables window that
> #{dialog} points to a BasicDialogContext that internally has 2
positions:
> one for my parent dialog, together with its data, and one for me, as a
> subdialog, together with my own particular data (which at this time is
> empty).
>
> The problem is there is no way to access my parent's data, because using
> #{
> dialog.parent} is oriented to some other use cases, I guess, like a
popup
> (as you need to provide some request parameters).
Yep ... it's designed for the popup or separate-frames use cases, not for
subdialogs.
So my question is: can I start a dialog, create some data for that dialog,
> and then start a subdialog, and be able to access my parent's data? I'm
> afraid this is not possible...
That's a good question ... the state data is actually stored inside the
DialogContext instance (in a stack), but is not accessible directly. We
definitely need a way for subdialogs to get to that state information
(analogous to what "parent" does for popups). Need to think a bit on how
to
do that ...
Thanks.
>
>
Craig
