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:
>
>>
>> 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.
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.
> 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.
> 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.
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
