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

Peter Stavrinides updated TAP5-411:
-----------------------------------

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



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




Some bad description corrected.

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

Reply via email to