It only caches one view at a time.
On Tue, 08 Mar 2005 00:09:10 +0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Heath, > > > If you search the archives, I'm sure you can find more details, but > > here's the short version: > > This an interesting problem and thank you for taking the time to educate me. > I'll check out the archives. > > > > > If you're using server-side state saving, the spec requires that you > > save a copy of the serialized component-tree state on the session. > > The spec also says that if a request comes in for a view that is has > > not been serialized in the session that the lifecycle must just render > > the view, save a serialized copy on the session and do nothing more. > > > > Thus, if the user clicks the back button, the saved view is out of > > synch, so anything they do on that page will just result in a > > redisplay of the same page. Then, the saved view is in synch again, > > and they can do what they want. > > I don't quite understand why the serialized server state would be out of > sync if the session was not invalidated or the component tree still was > cached in session with the rest of the views. I guess that there is a > maximum number of saved views cached in the session too? > > > > > Client-side state saving doesn't have this problem. The easy solution > > is just to use that. > > > > > > Gary > > -- -Heath Borders-Wing [EMAIL PROTECTED]
