[
https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Kemnade closed TAP5-411.
-------------------------------
Resolution: Invalid
We assume this is no longer relevant and therefore close it.
If you still have this issue in a recent Tapestry version (such as 5.3.8 or the
latest 5.4 preview release), feel free to provide the necessary information and
reopen.
> 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.3.4#6332)
