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
Craig
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
------------------------------------------------------------------------
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
Paul Spencer
