[
https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13090144#comment-13090144
]
Peter Stavrinides commented on TAP5-411:
----------------------------------------
Hi Robert,
I am glad that you too see some value in this persistence strategy, imho it
would be unbelievably useful, which is why it is at the top of my wish list.
> The tricky part of this issue is determining what defines "navigating away
> from the page".
I believe the only correct behaviour, and the most natural would be to consider
"navigating away from the page" to be when all instances of the page (tabs /
windows) are closed.
> 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: tapestr5-review-for-closing
>
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
