On 8/25/06, Paul Spencer <[EMAIL PROTECTED]> wrote:
Craig,
Thank you for the explanation. It was very helpful.
1) Would you like me to post it on Shale's WIKI?
That would be great.
2) "SHALE-184 Provide new "Dialog Scope" for managed bean scope"
looks like what the functionality I need. This would allow
for the conversion from session managed beans to dialog managed
beans without changing the JSPs that reference those beans
or any other code changes.
That's definitely one of the motivations for this. If we can hide the
trickery of getting the right dialog-scoped bean into a magic variable
resolver or property resolver, we can make life very easy on the page
developer who wants to make this kind of transition.
3) I found the "Dialog Manager Feature" wiki page[1] where
the requirements for an updated Dialog Manager are
being discussed. Is this the primary focus of the
next release of Shale?
Definitely ... it would be ideal if we can get a fixed version of this for
ApacheCon US in October, and this is the most important individual feature
we want to address. There's also active discussions about what to do on the
dev list ... you're welcome to join in over there too.
Craig
[1] http://wiki.apache.org/shale/DialogManagerFeature
Paul Spencer
Craig McClanahan wrote:
> On 8/25/06, Paul Spencer <[EMAIL PROTECTED]> wrote:
>>
>> I am converting from a session managed bean to a Shale Dialog using
>> a request managed bean. The problem I am currently having is the fields
>> in the managed bean are being restored on subsequent request. The
>> application worked with a session managed bean, so is suspect I have
>> not added support to save/restore state to the bean. If this is the
>> case, what do I need to add to the managed bean?
>
>
> It worked in the session managed bean case because the server saved it
for
> you (in the HttpSession). The analogous capability with dialogs is to
save
> it in the "data" object that the Dialog Manager provides. Internally,
this
> is kept in the HttpSession as well, but it is thrown away for you when
the
> dialog ends.
>
> The data storage area that the Dialog Manager provides for you is in a
> session scoped bean named "dialog", which has a "data" property in it.
> Your
> application can store anything it wants there ... typically, you'll
either
> use a JavaBean that has properties for all the stuff you want to save,
or
> just a Map if you don't want to bother creating one. Given this, you
can
> use value binding expressions like "#{dialog.data.foo}" to reference
> property "foo" in your data object. Indeed, it's quite convenient to
bind
> the JSF components in the pages of your dialog directly to this data
bean,
> so you don't have to be copying stuff back and forth.
>
> All this theory sounds wonderful, but where's the code? A good example
of
> this is in the Use Cases example application, in the part that handles
> logging on and/or creating a new profile. The dialog starts with an
action
> call to the "setup()" method in EditProfileActions.java, which (among
other
> things) stores a new object of type EditProfileState into the data
> property,
> like this:
>
> EditProfileState state = new EditProfileState();
> ... initialize things ...
> setValue("#{dialog.data}", state);
>
> The pages of this dialog (profile1.jsp, profile2.jsp, and profile3.jspin
> the "profile" subdirectory) all have direct bindings to properties of
this
> state bean, so the app doesn't have to copy anything as the user
navigates
> between pages. When the application logic needs access, such as in the
> finish() method of EditProfileActions that finishes things up, it can
grab
> the object:
>
> EditProfileState state = (EditProfileState) getValue("#{dialog.data
}");
>
> and go do whatever needs to be done. When the dialog completes, the
> framework will release its reference to this bean so that it can be
garbage
> collected.
>
> A word of warning, though ... there's a number of outstanding bugs (see
the
> JIRA open bug list on Shale for details) related to the dialog feature,
and
> we're actively reviewing the implementation. It's possible that some
> details of how this works will need to change to address those issues,
> although we'll strive to be consistent with current practice when we
can.
>
> Paul Spencer
>
>
> Craig
>
