[jira] [Updated] (TAP5-411) A persistence strategy to provide page state that persists until the user navigates away from the page

["Jochen Kemnade (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jochen Kemnade updated TAP5-411:
--------------------------------

    Labels: bulk-close-candidate  (was: tapestry5-review-for-closing)

This issue has been last updated about 1.5 years ago, has no assignee, affects an old version of Tapestry that is not actively developed anymore, and is therefore prone to be bulk-closed in the near future.

If the issue still persists with the most recent development preview of Tapestry (5.4-beta-6, which is available from Maven Central), please update it as soon as possible. In the case of a feature request, please discuss it with the Tapestry developer community on the dev@tapestry.apache.org mailing list first.


> A persistence strategy to provide page state that persists until the user navigates away from the page
> ------------------------------------------------------------------------------------------------------
>
>                 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
>              Labels: bulk-close-candidate
>
> 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
> Persists a value for a page for the duration of a session: 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("?")
> 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 associated persisted values.
> More on this in this thread here:
> http://www.nabble.com/Persistance-td20732003.html#a20732003



--
This message was sent by Atlassian JIRA
(v6.2#6252)