On 1/24/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Craig, I added my comments at the end. Craig McClanahan wrote: > On 1/24/07, Paul Spencer <[EMAIL PROTECTED]> wrote: >> >> I need to use an existing JSF page in a dialog. How to I tell the 1.0.4 >> Dialog manager which request scoped beans to maintain through out the >> dialog? > > > That is a really interesting idea. The reuse idea was one of the original > motivations for the approach we took in designing the dialog APIs, and > making this possible without modifying the binding expressions used by the > page is a missing link in the current implementation. > > Is their a way to do this in the dialog configuration? >> >> I was hoping for something like: >> <dialog ...> >> <beans> >> <bean name="renamedBean" value="#{requestScopeBean1}"/> >> <bean name="requestScopeBean2"/> >> </beans> >> </dialog> >> All of the the views would have access to #{renamedBean} and >> #{requestScopeBean2} > > > The 1.0.4 mechansim for saving state does not directly support this use > case. It expects you to store all of the dialog state information via the > "data" property of the DialogContext for the active dialog instance, which > is made available via the "dialogScope" pseudo-variable (which partially > addresses SHALE-184, but a real solution is going to require changes to the > JSF specification). > > It is feasible to implement adding a list of "please save and restore this > stuff for me" configuration, as you describe above, although I would > want to > look at whether we can make an SCXML based approach function similarly. > Another strategy would be to add onActivate() and onDeactivate() callbacks > on DialogContextListener, so an application could perform its own custom > save and restore logic. For covering the common cases, we could provide a > simple implementation that you configured with a bunch of VB expressions > (like your configuration example) and did the save/restore stuff. This > way, > we could add the functionality without having to get into the guts of the > dialog implementation on applications that do not need this service. > > What do you think? > o Implementation should work for all dialog implementations, basic and scmxl.
Agreed. o In the case of SCXML dialogs, the bean mapped, i.e. requestScopeBean1
is mapped to renamedBean in the my example, should not be part of the scxmlconfig. This will allow the SCXML configuration to be reused in may dialogs.
There are actually two configuration files for SCXML ... the one that conforms to the SCXML definitions (which we cannot change), and the one that adds Shale-specific information (such as the name of the class to use for the "data" object. We'd be able to modify that, if we wanted to pass the configuration information in. o For simple dialogs only configuration changes should be required, the
implementation of a interface like DialogContextListener, should not be required. The default DialogContextListener implemention should do the "please save and restore this stuff for me" in onActivate()/onDeactivate().
Isn't the list of what request scope beans you want to save and restore going to be specific to each dialog definition? I agree that we should provide a listener implementation that does the work, but it will still need to be configured. Separately but related, I'm thinking that the configuration information would be a set of zero or more value binding expressions. Saving the state information would end up calling getValue() on these, and storing in session scope, while restoring will mean calling setValue() on the value binding. This should work for request scope variables ... for an expression "#{foo}": * Caling getValue() will look up this variable in any scope ... thus will find it in session scope if it is there. * Calling setValue() will cause a new request scope variable to be created. Doing this lets us cover the simple case of entire attributes, but also gives the developer the freedom to save and restore properties of an existing scoped bean, instead of just scoped beans themselves. Also separately but related, it seems to me that someone using this approach would not need the "data" property of DialogContext explicitly. Thus, we could offer a concrete implementation bean that does the save/restore stuff for you, and is configured by setting a list of expressions. The DialogContext implementations already notice when the data class is a DialogContextListener, so adding the onActivate()/onDeactivate() methods to the event signature should be all the wiring we need. (This will make more sense when I work out a concrete example ... but I think we can dispense with modifying the configuration DTDs at all.) o The user should be able to convert from a series of views that use a
session scoped bean to pass the data between views to a dialog using request scoped bean with the following configuration changes: 1) Change the scope of the session bean to request. 2) Define the dialog 3) Update the actions to reference the dialog
That makes a lot of sense, but I don't think step 3 is actually required. As part of step 2, you will just need to make sure that you define transitions for all of the possible outcomes that the actions can return, and you should not have to modify the actions themselves (or the pages that used value binding expressions to the state data). That's a pretty elegant migration path.
Craig > Paul Spencer
Craig