[jira] [Commented] (TAP5-411) A persistence strategy to provide page state that persists until the user navigates away from the page
[ https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090951#comment-13090951 ] Peter Stavrinides commented on TAP5-411: It's not that simple. If you have the page open on two tabs, the most natural approach is they have separate per page stores. No, better to use conversational state in this case (a tab is either independent or it isn't). It can be simple in my view, if they reference the same id, exactly as a session scoped page would, with the one single difference being when to terminate this reference; and that would be when an active instance can no longer be found, this is the only tricky bit to solve. If you think of it like that then all the rest falls into place, anything else will overcomplicate it and cause functional faults. 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
[jira] [Commented] (TAP5-411) A persistence strategy to provide page state that persists until the user navigates away from the page
[ https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (TAP5-411) A persistence strategy to provide page state that persists until the user navigates away from the page
[ https://issues.apache.org/jira/browse/TAP5-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090280#comment-13090280 ] Kalle Korhonen commented on TAP5-411: - It's not that simple. If you have the page open on two tabs, the most natural approach is they have separate per page stores. Also, what happens when the user refreshes the page? Typically, you don't expect that to be counted as navigating away from the page. 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
