Hi,
On Thu, Mar 6, 2014 at 9:29 AM, Tom Götz <t...@decoded.de> wrote: > Hi there, > > I have an application that doesn’t need back-button support and also has > several domain objects that are not meant to be serialized. I thought it > could be a good idea to implement an IPageStore that skips serialization > and simply keeps the last n pages in memory (where n might be 5-10 e.g.). > Does this sound like a reasonable plan or do you see any pitfalls with that > approach? > Where you will store the pages ? I guess you will put them in the Session. Be aware that the Wicket Session is stored as an attribute in the Http session. You will need custom ISessionStore if you want to avoid this. If you put non-Serializable objects in the http session then you have to make sure the http session is not replicated by your web container. > > What about ajax requests (I’m using a lot of them)? Let’s say n=5, i.e. > I’m storing (only) the last 5 pages in memory, without serialization to > disk. I start a page, pageId==1, then I’m doing 10 ajax requests on the > page. Now when the user does a page reload, will he run into a > PageExpiredException because the requested page with id=1 is not available > any more in my pageStore? > This is not how it works! Initially you store page with id X. In Ajax requests the pageId is not incremented, so after Ajax request the old page instance will be overridden by the new one (the one with the modifications done in the ajax request) because it has the same pageId. So in your example when the user does page reload (s)he will see the last version of the page, i.e. the state after the last Ajax request. All previous states will be gone. All this is valid only if you use the same composite key for the page store - sessionId+pageId. > > Cheers, > -Tom > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >