shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Gary VanMatre)
Subject Re: [dialog] Get rid of subdialogs
Date Thu, 24 Aug 2006 18:43:54 GMT
>>On 8/24/06, Sean Schofield <> 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 #{} 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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message