[
https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655706#action_12655706
]
Peter Stavrinides commented on TAP5-411:
----------------------------------------
Yes, sorry Massimo, I wasn't clear persist provides page level persistence
(what I meant to say is that the value is persisted for the duration of the
session)
Hugo, thats absolutly right, forget my bad naming, the point I am trying to
make is about the life-cycle (how long the value persists and when it gets
cleared), which I beleave should match the implied life cycle of a page. (a
page as we know is pooled so the actual life cycle is not applicable)
Depending on your use case you might want a value to persist in all windows or
in one (as is the case for conversational state).
> 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]
