Hi .... Yeah in our T4 app we don't use @Persist at all and we really control the session-size ... we have been setting up to open source this code that handles the session issues.
I have been wanting to get the code in better shape before releasing back to the community ... but it is good enough. .. I just submitted the project to sourceforge for consideration. I have to wait a few days for approval. Patrick Moore Amplafi http://amplafi.com 650-207-9792 "copy/paste" blog : http://www.sworddance.com/blog On Sat, Nov 29, 2008 at 6:19 AM, Marcelo Lotif <[EMAIL PROTECTED]> wrote: > I think this is very interesting too, and I have implemented something like > this in a menu component I've made, but the solution is specific to my > case. > > This persistence strategy would be a nice improvement, and would solve some > problems we had with the session size. > > On Fri, Nov 28, 2008 at 7: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] > > > > > > > -- > Atenciosamente, > > Marcelo Lotif > Programador Java e Tapestry > FIEC - Federação das Indústrias do Estado do Ceará > (85) 3477-5910 >
