If they wander off and come back later, then I would call it a feature
;-)
If they press cancel, though, it really should go away.
You could use a utility Action in place of the global forwardings, that
would remove the session bean, and then continue on to the original
destination. The name of the bean to remove could be the parameter
property, and the global forward given as a "continue" local forwarding.
public ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
request.getSession().removeAttribute(
mapping.getParameter());
return mapping.findForward("continue");
}
Again, this could be used for any workflow that involves a session bean.
Just change the parameter property and the local forward. I use it as a
logout Action.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> I have a multi-page transaction that uses a session-scoped form bean. The
> action class that carries out the final transaction cleans up the form bean
> from the session. The catch is that on earlier pages there are links that
> allow the user to short-circuit the business transaction (cancelling it
> effectively) and take them to some other destination. Those links either
> have actions that are unrelated or are simple global forwardings with no
> associated action.
>
> What happens is that when they short-circuit like this, the form bean is
> never cleaned up, and if they start a new one of these multi-page
> transactions subsequently within the same session it begins with state from
> the previously short-circuited operation.
>
> I could claim that this is a feature. ;-)
>
> I could create a "cancel" action that cleans up the form bean and always
> returns a "success" logical forwarding, and use that as the action for the
> short-circuit links. These is the easiest solution I have come up with,
> but I thought I would see what you folks have to say.
>
> Jim
>
> Jim Weaver
> Software Developer - ThoughtWorks
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
