Johan Compagner schrieb:
Ajax don't have back button problems because the history doesn't
change in the browser
(at least as long as the client doesn't do that through javascript)
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.
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'.
then knowing at the serverside that you sometimes have a ajax request
with state and then nothing again.
But this also is the same for normal request (link clicks or form
submits) These request after a ajax call
must also all be changed after the first ajax call because else they
will send over the wrong state.
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.
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.
i have just made another attempt to have session state reduced but
still no client state..
this can be tested in the branch:
https://svn.sourceforge.net/svnroot/wicket/branches/clientpagestate/wicket
Here we have now a SecondLevelCacheSessionStore and a FileStore which
can be used by an application
by specifiying it in the method:
/**
* @see wicket.protocol.http.WebApplication#newSessionStore()
*/
protected ISessionStore newSessionStore()
{
return new SecondLevelCacheSessionStore(new FileStore());
}
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?
Thanks,
Christian
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
