You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Peter Stavrinides (JIRA)" <ji...@apache.org> on 2008/12/11 15:51:44 UTC
[jira] Created: (TAP5-411) A persistence strategy to provide page
specific 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-411) A persistence strategy to provide page
specific state
Posted by "Peter Stavrinides (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Updated: (TAP5-411) A persistence strategy to provide page
specific state
Posted by "Peter Stavrinides (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-411) A persistence strategy to provide page
specific state
Posted by "Hugo Palma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655693#action_12655693 ]
Hugo Palma commented on TAP5-411:
---------------------------------
Yeah, i don't agree with "page" for the proposed new persistence strategy.
The goal here, like it was discussed on the referenced thread, is for a new persistence strategy to provide page level persistence (just like the "session" strategy) but that gets cleaned when the user navigates away from the page.
Right Peter ?
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Commented: (TAP5-411) A persistence strategy to provide page
specific state
Posted by "Massimo Lusetti (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655691#action_12655691 ]
Massimo Lusetti commented on TAP5-411:
--------------------------------------
That not correct, @Persist annotation is for "per page" persistence, @ApplicationState is for "per session" persistence
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org