Craig,
I embedded my comments. They are near the end.
Paul Spencer
Craig McClanahan wrote:
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.
Yes, the list of beans is specific to a dialog.
Up to this point the beans have been request scope. What if the user
configures a session or application scope bean? On the face it seems the
save/restore process will be wasted work, but can/should a request a request
scope bean be created? Thus the bean will have a request and
session/appliction set of
properties.
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.)
1) Yes, the data property of DialogContext would not be needed.
2) I am not sure what you mean by "configured by setting a list
of expressions". The exact details around how the list of beans
to be saved/restored is configued can be detemined later.
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.
The actions will need to change. They may be "addPage1", "addPage2".. and will
change to "dialog:add", "next",....
Craig
>
Paul Spencer
Craig
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.10/651 - Release Date: 1/24/2007 6:48
PM
