tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Zeigler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TAP5-411) A persistence strategy to provide page specific state
Date Thu, 18 Aug 2011 07:28:27 GMT

    [ https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086854#comment-13086854

Robert Zeigler commented on TAP5-411:

I think the issue is still valid.  The addition of the session attribute feature doesn't change
the value of this request.  At the core, this issue is asking for a new page-level persistence
strategy that retains the values until the user navigates away from the page.  Session attributes
are application-wide, and they exist until you explicitly remove them.  Adding the new persistence
strategy would make it much easier to deal with Tapestry's redirects after actionlinks/evenlinks/posts.

The tricky part of this issue is determining what defines "navigating away from the page".

Suppose I have two tabs or windows open to the same page and I navigate away from the page
in one of the tabs/windows? What then?
Does closing a tab count as navigating away from the page? What if two tabs are open to the
same page and I close one of the tabs?

If a viable solution can be found to the navigation problem, this is worth implementing. 

> 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
>              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


View raw message