(at least as long as the client doesn't do that through _javascript_)
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)
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.
So this is not that easy to do. And what is the real gain?
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.
the only drawback this method has is the same as with client side saving.. And with clientside saving you will
have it always instead of now only when the filestore is hit for a page. And that is when you are sharing models
over pages. Because if you do that and the page is serialized (to the client or to the server disc) then the models
will be out of sync after that.
This secondlevelcachestore will also switch of the multiwindow check. Because that is not needed because all pages
can be reconstructed for a session.
johan
On 4/30/06, Christian Essl <[EMAIL PROTECTED]> wrote:
Johan Compagner schrieb:
> but that is not client state.
> That is serverside state. the unique id you are talking about is the
> page id.... pointing to a page instance.
>
> So what is the point of having a client side state if you work that
> way. as far as i can see zero.
>
Hi Johan,
Thanks for your answer. I certainly understand wicket too little but I
think:
You only store a page instance in the Session if the page makes an AJAX
call - otherwise not. You evict the page-instance on the server when the
AJAX-Page unloads. You also do not have to save version-data. For non
AJAX-Pages anway. And for AJAX back-button support you serialize over
the last state-change and the client sends the last change back when it
intercepts the back-button (Does Wicket support the back-button with
AJAX out of the box? would be cool.).
IMO in essence you need at most keep as many pages in the session as the
maximum number of Browser-Windows you eccpect the user to have open at
the same time. And than you have its full state including all the back
button and multi windows.
Thanks,
Christian
>
> On 4/30/06, *Christian Essl* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Matej Knopp schrieb:
> > Johan Compagner wrote:
> >> this is pretyt much all in place.
> >> I don't believe in a cookie and or url state what is that?
> storing a
> >> page in an url?
> >>
> >> We have a branch where we have a first draft of ClientSide Page
> >> saving (in an _javascript_ variable that is then set in a hidden
> field
> >> of all the forms)
> > How will hidden field work with ajax? Will every response have to
> > carry the whole (new) page state?
> Sorry for this question from the gallery, but I am also intressted in
> client-side state with AJAX, albeit in another project.
>
> My assumption is that with AJAX you have the advantage that an
> AJAX call
> does not have the new-window or back-button problem. Requests
> generated
> by this 'problems' are never Ajax-Requests and if you handle the
> back-button with AJAX you will catch it in _javascript_ anway and
> have an
> explicit event. IMO this makes things easier with AJAX and I
> thought you
> could use for regular requests client-side-state and for AJAX the
> Session.
>
> What I think of is that the first AJAX call will have to send the
> client-side-state, but than this state can be kept in the Session
> under
> some random unique-key. The first AJAX response than sends back the
> unique-key to the client which keeps it and all further AJAX requests
> than just transmit this unique-key back to the server (and not the
> full
> state, because this is kept in the Session). After the AJAX calls when
> the first regular request comes to the server the request is
> checked for
> the presence of a unique-key and if so the state transmitted by the
> request is dismissed and replaced by the one in the Session, which is
> than again send back to the client for client-side-state-keeping. And
> the thing starts over.
>
> I think this way you can go to some extend around the AJAX ClientSide
> state problem.
>
> Would be great if you could share your thoughts about that.
>
> 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
> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> <mailto:[email protected] >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.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
