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.
That's true. Client-side-state has of course the disadvantage of only
post-links, higher-bandwidth, more processing etc. And if the
mulit-window problem is not present than server-side state is propably
better. My point was rather how to solve the AJAX problem with
client-side-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.
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.
It's not too hard to do that (if you do AJAX anyway), but because of the
asynchronous nature of AJAX I'd now rather render with each form the
timestamp and than use this one as the key. The first AJAX requests
sends the data and this timestamp and further requests only send this
timestamp. The servers saves the state in the Session under the
timestamp and the server knows if the timestamp is present in the
Session than the client's post-data is stale.
>
> 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)
That's right, client-side-state has this limitations. But I think you
also have to take care when you store to the File-system to get no
bottleneck there maybe you make this plugable for a DB (not a RDBM).
Thanks for your points.
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
