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
