And as you said the pages whould be HUGE because every link then have that page state encoded in the link over and over again
so 20 links on one page would be 20 times 2K just for all the links.
So that is really not an option.
You don't have to serialize the whole http session
only 2 objects: the wicket session and the current page (and the pagemap but the pagemap isn't usefull at all in this situation, it doesn't do anything)
this i don't get:
"ClientPageSavingSessionStore now presumes that the last request was
encoded by Wicket, but that is a problem for things like shared
resources and bookmarkable pages. "
that doesn't matter. a shared resource or bookmarkable url call just don't have the wicketstate hidden field in the request
so the page is not deserialized and put in the map. But that map doesn't have to be filled because the request isn't comming in for an existing page.
johan
On 10/21/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 10/21/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> no that is only done half way it is not really usable, just a test case how
> it could be done..
> When we don't finish it (i don't think i will do that) then it should be
> removed before the final of 2.0
Yeah, we should remove it then. Looking at it, we would need a
different strategy for that anyway. It would be more like:
1) This session store should get the session like eg.
HttpSessionStore. I think trying to encode the whole session would be
just too much (and we're not actually even doing that here).
ClientPageSavingSessionStore now presumes that the last request was
encoded by Wicket, but that is a problem for things like shared
resources and bookmarkable pages. The thing we want encoded is the
state of the last request if that is relevant for call backs (in
effect the rendered page).
2) StateWriter is something we would need, but it would need to be
extended to converting all links to use a submit too. For this we
would probably need to have a _javascript_ function that dynamically
builds a form or post. Links etc would be converted to use this.
2a) I learned recently that 255 is not an actual limit for gets, but
merely a very outdated 'recommeded' length. For internet explorer this
maximum is 2,048 (http://support.microsoft.com/kb/208427 ) and I read
other browsers even exceed that. I haven't measured it, but wouldn't
that be enough for one serialized page to hold? A thing to consider is
not to worry about posts in the first place (you could argue this is a
trade off users have to consider themselves), but put this encoded
state in the links we return in urlFor. We could do that, as the
complete hierarchy is known in 2.0. Additionally, with that method,
there could be a nice optimization, where we ask the component itself
for it's 'contribution' to the encoded state (don't aks me how that
would work right now, it's just a wild thought). Of course, there
would be the overhead that every link on the page would have that full
state initially, but that would be something we could optimize later
as well.
3) The session store should only intercept the getAttribute requests
for the page map. On that request, it should return an on-the-fly
pagemap, with the one page reconstructed from the session state that
was sent with the request. That pagemap could be lazily constructed
and reused throughout the request, and onEndRequest it would be
cleared again.
These are just a bunch of wild thoughts. I'm convinced that if we
wanted and 2a would be viable, we wouldn't be that far off to working
client side state saving. The nice urls 'problem' that this thread
started with is still something else, and I agree with Johan and Matej
that there are a number of problems with it (most notably mounting and
redirect to buffer not working), and thinking about it a bit more,
even though we probably could achieve something like this if we really
tried hard, it wouldn't be for any advantage other then that the urls
would like 'nicer'. The thing that I proposed in a thread two weeks
ago: components contributing 'state' to urls would at least have the
advantage of bringing totally tweakable stateless pages a step closer.
This case doesn't have that advantage. And concerning client side
state saving, I'm still unconvinced that this is better to have than
just server state saving. On the contrary. The only thing interesting
about it is the technical challenge and the additional choice it would
provide our users.
Eelco
-------------------------------------------------------------------------
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
------------------------------------------------------------------------- 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 Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
