The old WebObjects backtracking feature (a similar concept) kept only the last 30 pages by default. If the user got too busy with the back button he'd get an error page "You backtracked too far."
----- Original Message ----- From: "Pablo Ruggia" <[EMAIL PROTECTED]> To: "Tapestry users" <tapestry-user@jakarta.apache.org> Sent: Tuesday, May 17, 2005 1:01 AM Subject: Re: Tapestry's Simplicity Blues On 5/12/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > > Sent: Thursday, May 12, 2005 9:11 AM > > To: Tapestry users > > Subject: Re: Tapestry's Simplicity Blues > > > > Wish I had had the foresight five years ago to build in explicit > > support for a visual builder. > > > > 4.0 is adding flexibility to store state in many places, currently in > > the session (as in 3.0) but also as query parameters / hidden form > > fields. Further nuances will likely be possible in the future as well > > ... I'd like to see support for WebObjects style state storage, where > > multiple versions of the property are stored on the server, and the > > client includes query parameter to select which version was in effect > > when the page rendered. > <snip> > > I actually rolled a (primitive) version of the functionality you're > describing last week. Each of my pages now has "base" properties and > "persistent" properties. All persistent properties aren't stored in the page > object, but rather in an attached persistent object e.g. > > Public class foo extends BasePage { > > Private FormProperties fPersistentProperties; > Private String fSomeNonPersistentString > > Public String getSomePersistentProperty() { > Return fPersistentProperties.getSomePersistentProperty(); > } > > Then the when the page starts rendering I generate a unique key for this > particular page rendering and stuff it into the page as it renders. After > page render I then drop the persistent properties into a linked hashmap in > the visit object, using the previously generated key. > > Then, whenever any link or button on the aforementioned form is clicked on > the client, I bootstrap the page back into the appropriate state by yanking > the persistent properties out of the visit object by way of the key. > > It seems to be working fine for me, although it's a wee bit expensive on the > memory front, burning about 200 bytes per page render, so I had to put a cap > on the number of pages I remember per user and only keep around the last 100 > pages per user. If the user clicks a link that references a page that's been > flushed, I just throw a stale link. > > The specific code's pretty closely linked to my particular implementation, > but the approach might work in a more general case approach. > > --- Pat > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > I'm doing something similar, I like this aproach. But i'm really afraid of how much memory it will eat up, and I can't estimate what a reasonable limit of pages to save is. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
