Craig,
I embedded my comments.
Craig McClanahan wrote:
On 1/24/07, Paul Spencer [EMAIL PROTECTED] wrote:
Craig,
I embedded my comments. They are near the end.
Paul Spencer
Craig McClanahan wrote:
On 1/24/07, Paul Spencer [EMAIL PROTECTED] wrote:
snip
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.
It is technically legal to have beans with the same name in different
scopes. The EL evaluation rules guarantee that the same order will be
followed (request, then session, then application), at least for expression
evaluation, so the results will be predictable.
I think your point about wasted work is key ... if you are already keeping
your state information in session or application scope, you do not *need*
this new mechanism, so you should keep on doing what you are doing. The
accesses to sesion and application scope data will still work inside the
dialog execution.
If the user wants to configure a session or application scopes bean, they
can and it will work.
Cool
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.
Yah, I was kind of hand waving there :-). I've checked in the first steps
of the mechanism, and am working on a concrete class that illustrates
what I
was talking about here in code instead of words ... hopefully that will be
easier to understand.
I look forward to using it.
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,
I agree that the link that starts the dialog would need to change, but is
there any reason you *have* to change the rest of them? It's certainly
possible to do so, but I don't think it would be a requirement for
migration.
I agree, you only have to change the action that starts the dialog
