Brendan Conner wrote:
In projects I've worked on, we've called it "conversation scope," since it represents a conversation with the user. We had similar scope issues with Struts, so we built our own framework that used the Session, but performed automatic cleanup on the Session for beans that were no longer in the "conversation." The framework used an XML file to associate each action with a list of beans that had to be present in the Session for that action. Then, it intercepted each request, deleting from the Session beans that were no associated with that request's action.
Yes, that approach is how most people seem to be doing it. But there turn out to be some nice benefits to carrying the state in the component instead:
* The programmers don't have to do explicit cleanup on "flow" exit. If you have lots of exit paths (as we do), this can start to get hairy. Also, we found that session-scoping made back-button support more unpredictable. Depending on where the user starts hitting "back", they get different results. Not an issue with component-carried state.
* The programmers don't have to explicitly decide when it's time to start a new "flow". Instead, we let the browser user handle it in the usual browser way.
* We don't end up piling data into session-managed memory for each supported active view. It's true that our flowState tag approach adds to the volume of request data, but a) we're mostly targeting a broadband network, and b) the amount of data carried is restricted to the single request's needs rather than being additive across all possibly active requests.
On the negative side, we do sometimes have that JSF annoyance with URLs going out of sync. As it turned out, though, the flow-scoped sequences we support wouldn't have been easily bookmarkable anyway.
Best, Ray
