>>On 8/24/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
>>
>> > I agree that, if we keep the concept of subdialogs around, mechanisms
>> for
>> > dealing with this are important. From the perspective of a subdialog, you
>> > should be able to "pull" data out of the parent dialog's context
>> > transparently (WebWork/XWork do this with their action context method).
>> > And, we would want to provide a way for a subdialog to "push" data u (at
>> > least) a level as well.
>>
>> What if we used dependency injection for the state object? Instead of
>> relying on this hard-coded #{dialog.data} business you could just have
>> a setData method that could be injected with an existing bean. IIRC
>> the current mechanism is that you provide your own data object by
>> calling setData from one of your dialog states.
>>
>> I think it would be cool if you could have something like
>>
>> <dialog name="Edit Profile" start="Setup" context="#{user}>
>>
>> where #{user} is a session-scoped bean defined in your faces-config
>> file. We could just make it a policy to clean it up after the dialog
>> ends (if that's your desire.) We could even make the cleanup optional
>> and only dump the context data if the bean implements a DialogCleanup
>> interface.
>>
>> I think this also solves the problem of storing states for multiple
>> simultaneous dialogs that have not yet finished.
>
>
>I don't see how this handles starting two instances of the same dialog at
>once (say, in two different windows), unless we can design some magic
>variable resolver that picks the right one somehow.
That's what I was thinking. The variable resolver could key off a "reserved"
variable name "DIALOG" or something.
It could search for the dialog token and use that to identify the dialog
context.
Use a default if the token doesn't exist in some scope. This assumes two
reserved EL names.
> Craig
Gary
