[ https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655691#action_12655691 ]
Massimo Lusetti commented on TAP5-411: -------------------------------------- That not correct, @Persist annotation is for "per page" persistence, @ApplicationState is for "per session" persistence > A persistence strategy to provide page specific state > ------------------------------------------------------ > > Key: TAP5-411 > URL: https://issues.apache.org/jira/browse/TAP5-411 > Project: Tapestry 5 > Issue Type: New Feature > Components: tapestry-core > Affects Versions: 5.1 > Reporter: Peter Stavrinides > > Perhaps the most commonly reoccurring persistence pattern is 'per page', as > opposed to session wide, or per request. Tapestry provides persistence > strategies for the later of these, but there is no strategy that mirrors a > pages 'implied' life-cycle. > @Persist > Provides session wide persistence across all pages: best used on primitives, > a disadvantage is that its open for abuse by incorrect use which will clutter > the session and increase its size thereby reducing scalability. > @Persist("flash") > A persisted object is removed after a post: - Not suited to all use cases > that require 'page specific' persistence... render methods can sometimes > prevent using flash persistence. > Currently the most scalable pattern for simulating page state is using > onActivate with onPassivate, and re-instantiating objects required for the > page, generally from their identifiers. > It requires more boilerplate code for checking that URL parameters are passed > correctly, particularly for pages that have 'optional parameters'... the > downside is more queries and having to use identifiers in URL parameters. > @Persist("conversation") > Seam provides this type of strategy, conversations provide a generally better > persistence context, persistence is associated to a single window / tab, for > which it retains state information between data requests/posts etc (whereas > its relatives, which are other windows or tabs will be independent to the > 'conversation') . Conversational state has been discussed in the past for > Tapestry. > @Persist("page") > The proposed strategy is along the same lines as conversational state, but > persisted values are retained for all instances of that page (regardless of > tabs or windows, meaning in practice that all active instances of that page > share an identifier), so closing all instances would remove ascociated > persisted values. > More on this in this thread here: > http://www.nabble.com/Persistance-td20732003.html#a20732003 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]