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
>
>

Reply via email to