Cool...Thanks
On 1/25/06, Rich Feit <[EMAIL PROTECTED]> wrote: > > 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? > > > > >
