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]
