Hey Daryl,
It solves a set of problems that involve multiple requests to different
page flows. Consider this:
- request A: hits x.jpf
- request A: nests y.jpf
- request B: hits z.jpf, blowing away the nesting stack
- request A: returns from y.jpf, gets EmptyNestingStackException
or...
- request A: hits x.jpf
- request B: hits y.jpf, making it the current page flow
- request A: forwards to a JSP that expects x.jpf to be current
The solution is to defer the committing of the nesting stack and the
current page flow (and shared flow, and JSF backing bean) until the end
of a chain of forwarded requests -- that way, the request state is
internally consistent. You can still end up with faulty app behavior
with two concurrent requests, but this gets rid of situations where our
framework itself gets confused (EmptyNestingStackException,
NoPreviousPageException, etc.).
The StorageHandler was originally the plug point where we could allow
storing page flow instances in alternate locations (e.g., database or
request). One thing that would be nice to change would be to have a
base class to support deferred-until-end-of-request storage in general,
so the logic could be used with locations other then the session.
Ultimately we should be able to have a storage handler that applies
per-pageflow, overriding the webapp-wide one.
Does this answer your question?
Rich
Daryl Olander wrote:
Rich,
Just curous what problem the DeferredSessionStorageHandler solves and in
general why we talk to the session thorugh the StorageHandlers? The tags
store everything directly in the session. Under what senarios do we ever
see having different implementations of this?
