That's not in 2.0 and I don't think it will be. Before you know it we will be doing premature optimization everywhere. Those stateless optimizations make sense for some cases, but for the rest, Wicket should focus on it's strong points: being OO and statefull. If we would have liked the way Tapestry and .NET handle things (because that is the way we would be heading), we wouldn't have had the need for Wicket. The cost for the stateful programming model is memory consumption. Cost doesn't equal problem here though.
We *might* give client state saving another go. Or not, as none as the core team members is convinced at this point it's better than the server side model we currently have, and of the several applications in production that I know of, memory consumption hasn't been a problem at all. Eelco On 6/13/06, John Patterson <[EMAIL PROTECTED]> wrote: > Just a quick question about how this will work in 2.0; is it > possible to have a page that has a normal link with an onClick > handler which is not stored in the session? > > In this case the link target would need to specify both the > BookmarkablePage and the Listener to call and when the target is > invoked it would need to instantiate the page and then call the > handler onClick method. So the page would be created twice but > probably rendered once. > > On 13 Jun 2006, at 03:07, Eelco Hillenius wrote: > > > Anyway, there is a solution for it now... deferred session creation > > :). It's in 2.0, didn't make 1.2 unfortunately, as it would mean two > > API breaks, but it is scheduled for 1.3 whenever that comes out (I > > guess that depends on how badly people want it) and you can apply the > > patch I sent earlier for 1.2. > > > > Eelco > > > > > > On 6/12/06, Alexandru Popescu <[EMAIL PROTECTED]> > > wrote: > >>>> Unfortunately this is not completely accurate information. > >>> > >>> I was writing about my experience and I wrote it down accurately. > >>> > >> > >> Timo, sorry if you found my comments as offending. There was no > >> such intention. > >> > >>> The session id is stripped from the link in the search result > >>> page. At > >>> least in the cases I had to deal with. That means that the user > >>> doesn't > >>> get a message like "session expired". > >> > >> Probably, I am missunderstanding the "session id is stripped from the > >> link in the search result page" part. I can see it there, and so the > >> user request will go to the /tralala;jsessionid=value. > >> > >> For me stripped from the link means: the link will not contain the > >> jsessionid part. But this is not true. It is there. Indeed the > >> application may continue to work correctly as it may create a new > >> session (so no error message will be displayed), but this is > >> something > >> that happens on the application side and not on the search engine > >> side. > >> > >> hth, > >> > >> ./alex > >> -- > >> .w( the_mindstorm )p. > >> > >> > >> _______________________________________________ > >> Wicket-user mailing list > >> Wicket-user@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/wicket-user > >> > > > > > > _______________________________________________ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
