> -----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]
