I think this feature would set Tapestry 5 even further apart from the rest, go
vote for it at:
https://issues.apache.org/jira/browse/TAP5-411
cheers,
Peter
----- Original Message -----
From: "Hugo Palma" <[EMAIL PROTECTED]>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Thursday, 11 December, 2008 12:52:37 PM GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: Persistance
I myself have found the need for such a persistence strategy.
I would suggest creating an issue for this so that people can vote and
follow it.
On Fri, Nov 28, 2008 at 10:23 AM, Peter Stavrinides <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have been thinking about persistence lately... and after moving all our
> apps from Tapestry 4 to Tapestry 5 this past year, I have noticed distinct
> patterns emerge in the way pages fit together and use persistence, and I
> have been searching all the while for best practices... here are some
> comments on how persistence evolved in my code:
>
> @Persist - I tended to use it a lot in the beginning, but far less now, I
> have found it optimal not to clutter the session, and therefore persist only
> a select few fields (mostly primitives).
>
> @Persist("flash") - I moved to flash persistence wherever I could, as it
> helps limit the number of queries required, but its not always feasible to
> use. On the odd occasion I also ran into problems with render methods when
> pages were complex.
>
> I now use mostly onActivate and onPassivate, this has proven to be the most
> reliable pattern, and the most scalable. It does require a bit more
> boilerplate code for checking that URL parameters are passed correctly,
> particularly for pages that have 'optional parameters'... the one downside
> is that I have a few more queries now.
>
> So whats missing in an ideal world? A read in a post some time ago that
> conversational patterns may be added in 5.1, that would be great! but what
> would be ideal in my humble view is a proper page persistence Strategy,
> where a value is retained until the user leaves the page. In truth someone
> posted such a solution which used a cookie, and it seemed to behave exactly
> as it should, nevertheless I am still against relying on a cookie. I
> understand this may be difficult to implement due to Tapestry's inner
> workings, particularly the way pages are pooled, but since conversational
> state covers some of this ground (the difference being a conversation is
> tied to not only the page, but the window so each tab is treated as a new
> conversation), I thought to at least to ask if it could be considered at
> some point if at all feasible. I would also love to hear other peoples
> thoughts/opinions on this.
>
> cheers,
> Peter
>
>
>
>
> ---------------------------------------------------------------------
> 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]
