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.
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.
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().
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
Craig
Paul Spencer
