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]

Reply via email to