That's what I said. But of course you can intercept the back-button in
AJAX and I just did not know wheter this is a requirement in Wicket. If
it is not in Wicket than well - just makes everything easier.
don't know exactly if you catch the back button to do a request to the server to display something else
it would be ok i guess. Igor is more the man to know the pittfalls on this one.
>
> Also i don't like this to much. Because if you do use ajax a little
> bit then the page is in the session anyway.
> And doing the right thing on the client side all ajax links must be
> ajax posts. (at least the first time)
> testing that it is the first time (doable by setting the special
> _javascript_ page variable to null)
That's exactly one line of JS code plus setting the the parameter of
AJAX-calls to 'post'.
this is not really true, first of all ajax calls are now just links
No post at all. But for client side state we have to rewrite all the links anyway..
But it is then still not one line of code. Because all the forms that are on the
page must be altered so that they know that they don't have to send the page state
but an unique id (the page id)
Ofcourse this is all doable but what is the real gain? If you do ajax on the clientside and the
chance is pretty great that it gets hit then don't do clientside for that page.
Or we could use the SecondLevelCacheSessionStore we now have in our branch then
we also have unlimited backbutton support and only one page (per pagemap) in the session.
No that's not true. They request after the AJAX call will send over the
wrong state but the server will know that it is the wrong state and
throw it away because the special hidden-field ('stale-state') will have
the unique-key in it and take the one in the session instead. So that's
easy to test on the server as well. I don't see what should be a problem
there.
that is just what i said instead of sending the page data when submitting a form
we must after the first call send the uid. when a form is posted.
So every form there is on the page must be altered after the first ajax call to replace
the pagedata with the pageuid.
>
> So this is not that easy to do. And what is the real gain?
Well because: No versioning, no PageMaps no strange urls, no
page-expired. You now when to unload an AJAX-Page because onunload you
will remove its key from the cookies. And it is just much more easy.
but all this can be archieved pretty easy with other implemenations which are far easier to use and implement.
And not everything must suddenly done through post and so on.
It is also much faster no serialization/deserialization and uuencoding everytime. Page are not that big because of the pagestate.
So bandwidth is spared (which is much more expensiver then some ram or extra machine)
> It only hold one page in the session per pagemap (the current one)
> But if a request comes in and it is another page then it goes to the
> second cache, this is a soft cache of pages.
> if it is also not found there it will ask the FileStore to get it and
> that one will get it from the WebApplicaiton work dir.
> you now pretty much have unlimitted back button support and a small
> session with only one page per pagemap.
When do you clear the FileStore?
currently only on Session invalidate.
But having a small thread that checks the session dirs and deletes them that aren't touched for X ammount of time is ofcourse very easy to build.
johan
