Craig,
Thank you for the explanation. It was very helpful.
1) Would you like me to post it on Shale's WIKI?
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.
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?
[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.jsp in
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
