Yeah, that's an alternative option - which I actually proposed in this thread yesterday - but the disadvantage is that you need to know quite a bit about Wicket's internals that way.
It would be great to have something smarter for things like this. I guess it's kind of the same thing Martijn proposes... component that have their own life span which is independent from the hierarchy they live in. I think we're also about to find out about some of the disadvantges of the proposed constructor change now. That constructor change will not make such an independent life span possible I think - at least not efficiently. I'm stumbeling in another disadvantage now too btw - a creational pattern that wouldn't be possible - but I'll leave that for another discussion :) I think we're about to arrive on a crossroads here, where we can either choose for the ultimate development safity (the constructor change, and a more rigid hierarchy) or more flexiblity (don't know how it looks yet, but something more in the direction of disconnected components which can be coupled to and decoupled from a hierarchy on demand. Eelco On 4/30/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
make youre own HttpSessionStore imp and PageEvictionStrategy. Hold a few page/page versions in mem. dump old pages to the database. And get them again only when requested. Delete everything when the session itself is invalidated... Unlimitted back button.. johan On 4/30/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > Yeah there's just no perfect world as long as browsers work the way they work. The big, really big advantage of client state saving is that there is no limit to history. You can work with internal links everywhere without ever having to worry they'll get stale. I found this an ugly limitation of keeping server state currently; if you want to create tabs etc, you generally have to use bookmarkable page links as otherwise you might run into the trouble of running out of versions. Eelco On 4/30/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > as always igor can say it so much better then i can :) > > But ajax and clientside state really isn't the best combination to have. > Because for every request the page state must be sent over and sent back. > > johan > > > On 4/30/06, Igor Vaynberg < [EMAIL PROTECTED]> wrote: > > > > > > > > > > On 4/29/06, Matej Knopp < [EMAIL PROTECTED] > wrote: > > > 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? > > > > > > > > > yep, ajax + clientstate = the suck > > > > > > -Igor > > > > > > ------------------------------------------------------- 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?cmdlnk&kid0709&bid&3057&dat1642 _______________________________________________ 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&kid0709&bid&3057&dat1642 _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
