You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Kalle Korhonen (JIRA)" <ji...@apache.org> on 2009/12/09 20:00:18 UTC
[jira] Created: (TAP5-948) Built-in mechanism to identify
self-referential links and/or event/render requests
Built-in mechanism to identify self-referential links and/or event/render requests
----------------------------------------------------------------------------------
Key: TAP5-948
URL: https://issues.apache.org/jira/browse/TAP5-948
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.0.18, 5.0.17, 5.0.16, 5.0.15, 5.1.0.5, 5.1.0.4, 5.1.0.3, 5.1.0.2, 5.1.0.1, 5.1.0.0
Reporter: Kalle Korhonen
Discussed on Tapestry user thread: http://old.nabble.com/Best-practice-for-initializing-page-to-default-context-td26689270.html
One of the cases where the issue manifests itself is that it's more difficult to initialize a page to default context than it needs to (and redirect to it) since event requests always cause a parameterless onActivate() to be invoked as well and there's no (framework-level) support for identifying event and render requests. There are many other uses for being able to easily identify links referring back to the same page.
Howard says:
"I've had to solve this problem for one of my clients as well and I think it's something that should go into the framework. The approach
I took was to identify self-referential links (page render links that are to the same page they originate from) using an additional query
parameter. This allows Tapestry to differentiate between requests that start on a new page vs. those that continue on the page. Tapestry can
then fire a notification on components to perform initialization (on page render requests without the query parameter).
This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm still working on the right terminology, for Widen it is "initialized", as in method pageInitialized()."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-948) Built-in mechanism to identify
self-referential links and/or event/render requests
Posted by "Peter Stavrinides (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794801#action_12794801 ]
Peter Stavrinides commented on TAP5-948:
----------------------------------------
This issue also relates back to this jira: https://issues.apache.org/jira/browse/TAP5-411 which is over a year old now. A new life-cycle method can be equivalent to a new persistence strategy, either way this is an annoyance that results in a large amount of unnecessary boilerplate code.
> Built-in mechanism to identify self-referential links and/or event/render requests
> ----------------------------------------------------------------------------------
>
> Key: TAP5-948
> URL: https://issues.apache.org/jira/browse/TAP5-948
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.0.15, 5.0.16, 5.0.17, 5.0.18
> Reporter: Kalle Korhonen
>
> Discussed on Tapestry user thread: http://old.nabble.com/Best-practice-for-initializing-page-to-default-context-td26689270.html
> One of the cases where the issue manifests itself is that it's more difficult to initialize a page to default context than it needs to (and redirect to it) since event requests always cause a parameterless onActivate() to be invoked as well and there's no (framework-level) support for identifying event and render requests. There are many other uses for being able to easily identify links referring back to the same page.
> Howard says:
> "I've had to solve this problem for one of my clients as well and I think it's something that should go into the framework. The approach
> I took was to identify self-referential links (page render links that are to the same page they originate from) using an additional query
> parameter. This allows Tapestry to differentiate between requests that start on a new page vs. those that continue on the page. Tapestry can
> then fire a notification on components to perform initialization (on page render requests without the query parameter).
> This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm still working on the right terminology, for Widen it is "initialized", as in method pageInitialized()."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-948) Built-in mechanism to identify
self-referential links and/or event/render requests
Posted by "Peter Stavrinides (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794801#action_12794801 ]
Peter Stavrinides commented on TAP5-948:
----------------------------------------
This issue also relates back to this jira: https://issues.apache.org/jira/browse/TAP5-411 which is over a year old now. A new life-cycle method can be equivalent to a new persistence strategy, either way this is an annoyance that results in a large amount of unnecessary boilerplate code.
> Built-in mechanism to identify self-referential links and/or event/render requests
> ----------------------------------------------------------------------------------
>
> Key: TAP5-948
> URL: https://issues.apache.org/jira/browse/TAP5-948
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.0.15, 5.0.16, 5.0.17, 5.0.18
> Reporter: Kalle Korhonen
>
> Discussed on Tapestry user thread: http://old.nabble.com/Best-practice-for-initializing-page-to-default-context-td26689270.html
> One of the cases where the issue manifests itself is that it's more difficult to initialize a page to default context than it needs to (and redirect to it) since event requests always cause a parameterless onActivate() to be invoked as well and there's no (framework-level) support for identifying event and render requests. There are many other uses for being able to easily identify links referring back to the same page.
> Howard says:
> "I've had to solve this problem for one of my clients as well and I think it's something that should go into the framework. The approach
> I took was to identify self-referential links (page render links that are to the same page they originate from) using an additional query
> parameter. This allows Tapestry to differentiate between requests that start on a new page vs. those that continue on the page. Tapestry can
> then fire a notification on components to perform initialization (on page render requests without the query parameter).
> This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm still working on the right terminology, for Widen it is "initialized", as in method pageInitialized()."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-948) Built-in mechanism to identify
self-referential links and/or event/render requests
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-948:
-----------------------------------------
Assignee: Howard M. Lewis Ship
> Built-in mechanism to identify self-referential links and/or event/render requests
> ----------------------------------------------------------------------------------
>
> Key: TAP5-948
> URL: https://issues.apache.org/jira/browse/TAP5-948
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.0.15, 5.0.16, 5.0.17, 5.0.18
> Reporter: Kalle Korhonen
> Assignee: Howard M. Lewis Ship
>
> Discussed on Tapestry user thread: http://old.nabble.com/Best-practice-for-initializing-page-to-default-context-td26689270.html
> One of the cases where the issue manifests itself is that it's more difficult to initialize a page to default context than it needs to (and redirect to it) since event requests always cause a parameterless onActivate() to be invoked as well and there's no (framework-level) support for identifying event and render requests. There are many other uses for being able to easily identify links referring back to the same page.
> Howard says:
> "I've had to solve this problem for one of my clients as well and I think it's something that should go into the framework. The approach
> I took was to identify self-referential links (page render links that are to the same page they originate from) using an additional query
> parameter. This allows Tapestry to differentiate between requests that start on a new page vs. those that continue on the page. Tapestry can
> then fire a notification on components to perform initialization (on page render requests without the query parameter).
> This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm still working on the right terminology, for Widen it is "initialized", as in method pageInitialized()."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-948) Built-in mechanism to identify
self-referential links and/or event/render requests
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-948.
-------------------------------------
Resolution: Fixed
Fix Version/s: 5.2.0
Came out quite nice, you just add a method named "pageReset" (or any method with @PageReset annotation) and the logic for "loopback" requests kicks in.
> Built-in mechanism to identify self-referential links and/or event/render requests
> ----------------------------------------------------------------------------------
>
> Key: TAP5-948
> URL: https://issues.apache.org/jira/browse/TAP5-948
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.0.15, 5.0.16, 5.0.17, 5.0.18
> Reporter: Kalle Korhonen
> Assignee: Howard M. Lewis Ship
> Fix For: 5.2.0
>
>
> Discussed on Tapestry user thread: http://old.nabble.com/Best-practice-for-initializing-page-to-default-context-td26689270.html
> One of the cases where the issue manifests itself is that it's more difficult to initialize a page to default context than it needs to (and redirect to it) since event requests always cause a parameterless onActivate() to be invoked as well and there's no (framework-level) support for identifying event and render requests. There are many other uses for being able to easily identify links referring back to the same page.
> Howard says:
> "I've had to solve this problem for one of my clients as well and I think it's something that should go into the framework. The approach
> I took was to identify self-referential links (page render links that are to the same page they originate from) using an additional query
> parameter. This allows Tapestry to differentiate between requests that start on a new page vs. those that continue on the page. Tapestry can
> then fire a notification on components to perform initialization (on page render requests without the query parameter).
> This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm still working on the right terminology, for Widen it is "initialized", as in method pageInitialized()."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-948) Built-in mechanism to identify
self-referential links and/or event/render requests
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-948:
-----------------------------------------
Assignee: Howard M. Lewis Ship
> Built-in mechanism to identify self-referential links and/or event/render requests
> ----------------------------------------------------------------------------------
>
> Key: TAP5-948
> URL: https://issues.apache.org/jira/browse/TAP5-948
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.0.15, 5.0.16, 5.0.17, 5.0.18
> Reporter: Kalle Korhonen
> Assignee: Howard M. Lewis Ship
>
> Discussed on Tapestry user thread: http://old.nabble.com/Best-practice-for-initializing-page-to-default-context-td26689270.html
> One of the cases where the issue manifests itself is that it's more difficult to initialize a page to default context than it needs to (and redirect to it) since event requests always cause a parameterless onActivate() to be invoked as well and there's no (framework-level) support for identifying event and render requests. There are many other uses for being able to easily identify links referring back to the same page.
> Howard says:
> "I've had to solve this problem for one of my clients as well and I think it's something that should go into the framework. The approach
> I took was to identify self-referential links (page render links that are to the same page they originate from) using an additional query
> parameter. This allows Tapestry to differentiate between requests that start on a new page vs. those that continue on the page. Tapestry can
> then fire a notification on components to perform initialization (on page render requests without the query parameter).
> This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm still working on the right terminology, for Widen it is "initialized", as in method pageInitialized()."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-948) Built-in mechanism to identify
self-referential links and/or event/render requests
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-948.
-------------------------------------
Resolution: Fixed
Fix Version/s: 5.2.0
Came out quite nice, you just add a method named "pageReset" (or any method with @PageReset annotation) and the logic for "loopback" requests kicks in.
> Built-in mechanism to identify self-referential links and/or event/render requests
> ----------------------------------------------------------------------------------
>
> Key: TAP5-948
> URL: https://issues.apache.org/jira/browse/TAP5-948
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3, 5.1.0.4, 5.1.0.5, 5.0.15, 5.0.16, 5.0.17, 5.0.18
> Reporter: Kalle Korhonen
> Assignee: Howard M. Lewis Ship
> Fix For: 5.2.0
>
>
> Discussed on Tapestry user thread: http://old.nabble.com/Best-practice-for-initializing-page-to-default-context-td26689270.html
> One of the cases where the issue manifests itself is that it's more difficult to initialize a page to default context than it needs to (and redirect to it) since event requests always cause a parameterless onActivate() to be invoked as well and there's no (framework-level) support for identifying event and render requests. There are many other uses for being able to easily identify links referring back to the same page.
> Howard says:
> "I've had to solve this problem for one of my clients as well and I think it's something that should go into the framework. The approach
> I took was to identify self-referential links (page render links that are to the same page they originate from) using an additional query
> parameter. This allows Tapestry to differentiate between requests that start on a new page vs. those that continue on the page. Tapestry can
> then fire a notification on components to perform initialization (on page render requests without the query parameter).
> This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm still working on the right terminology, for Widen it is "initialized", as in method pageInitialized()."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.