You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Vladimir Kovalyuk (JIRA)" <ji...@apache.org> on 2010/08/25 09:24:16 UTC
[jira] Created: (WICKET-3010) RequestCycle.setResponsePage should
defer switching to BookmarkableRequestTarget until finishing responding to
currrent target
RequestCycle.setResponsePage should defer switching to BookmarkableRequestTarget until finishing responding to currrent target
------------------------------------------------------------------------------------------------------------------------------
Key: WICKET-3010
URL: https://issues.apache.org/jira/browse/WICKET-3010
Project: Wicket
Issue Type: Improvement
Components: wicket
Affects Versions: 1.4.10
Reporter: Vladimir Kovalyuk
Once setResponsePage is called the AjaxRequestTarget is pushed down in the list of request targets and AjaxRequestTarget won't be called anymore because AbstractRequestCycleProcessor.respond invokes the current request target only.
My page has some ajax links that delegates handling to different module and link does not know whether redirect happens. The link still has to update some components. But in case of redirect all the updates aren't applied and backbuttoning shows old state (actually with ajax indicator covering all the page so any element is not clickable).
I believe it makes sence to defer switching to different request target until finishing responding on ajax request.
I found WebApplication.logResponseTarget(IRequestTarget target) as the place where I can actually apply deferred redirect. Please don't kill or make this method final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3010) RequestCycle.setResponsePage should
defer switching to BookmarkableRequestTarget until finishing responding to
currrent target
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902341#action_12902341 ]
Igor Vaynberg commented on WICKET-3010:
---------------------------------------
js should work for any kind of url you can generate, whether it is bookmarkable or not. as far as callbacks, see requestcycle#onrequesttargetset()
> RequestCycle.setResponsePage should defer switching to BookmarkableRequestTarget until finishing responding to currrent target
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-3010
> URL: https://issues.apache.org/jira/browse/WICKET-3010
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.10
> Reporter: Vladimir Kovalyuk
> Assignee: Igor Vaynberg
>
> Once setResponsePage is called the AjaxRequestTarget is pushed down in the list of request targets and AjaxRequestTarget won't be called anymore because AbstractRequestCycleProcessor.respond invokes the current request target only.
> My page has some ajax links that delegates handling to different module and link does not know whether redirect happens. The link still has to update some components. But in case of redirect all the updates aren't applied and backbuttoning shows old state (actually with ajax indicator covering all the page so any element is not clickable).
> I believe it makes sence to defer switching to different request target until finishing responding on ajax request.
> I found WebApplication.logResponseTarget(IRequestTarget target) as the place where I can actually apply deferred redirect. Please don't kill or make this method final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3010) RequestCycle.setResponsePage should
defer switching to BookmarkableRequestTarget until finishing responding to
currrent target
Posted by "Vladimir Kovalyuk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902365#action_12902365 ]
Vladimir Kovalyuk commented on WICKET-3010:
-------------------------------------------
I mean callbacks from within RequestCycle.steps() method. All I has found is Application.logEventTarget and Application.logResponseTarget invoked by AbstractRequestCycleProcessor. I use logResponseTarget to invoke setResponsePage at the end of the RESPOND step.
> RequestCycle.setResponsePage should defer switching to BookmarkableRequestTarget until finishing responding to currrent target
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-3010
> URL: https://issues.apache.org/jira/browse/WICKET-3010
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.10
> Reporter: Vladimir Kovalyuk
> Assignee: Igor Vaynberg
>
> Once setResponsePage is called the AjaxRequestTarget is pushed down in the list of request targets and AjaxRequestTarget won't be called anymore because AbstractRequestCycleProcessor.respond invokes the current request target only.
> My page has some ajax links that delegates handling to different module and link does not know whether redirect happens. The link still has to update some components. But in case of redirect all the updates aren't applied and backbuttoning shows old state (actually with ajax indicator covering all the page so any element is not clickable).
> I believe it makes sence to defer switching to different request target until finishing responding on ajax request.
> I found WebApplication.logResponseTarget(IRequestTarget target) as the place where I can actually apply deferred redirect. Please don't kill or make this method final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3010) RequestCycle.setResponsePage should
defer switching to BookmarkableRequestTarget until finishing responding to
currrent target
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902462#action_12902462 ]
Igor Vaynberg commented on WICKET-3010:
---------------------------------------
like i said, instead of setresponsepage use target.appendjavascript("window.location='"+urlfor(new mypage())+"'");
> RequestCycle.setResponsePage should defer switching to BookmarkableRequestTarget until finishing responding to currrent target
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-3010
> URL: https://issues.apache.org/jira/browse/WICKET-3010
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.10
> Reporter: Vladimir Kovalyuk
> Assignee: Igor Vaynberg
>
> Once setResponsePage is called the AjaxRequestTarget is pushed down in the list of request targets and AjaxRequestTarget won't be called anymore because AbstractRequestCycleProcessor.respond invokes the current request target only.
> My page has some ajax links that delegates handling to different module and link does not know whether redirect happens. The link still has to update some components. But in case of redirect all the updates aren't applied and backbuttoning shows old state (actually with ajax indicator covering all the page so any element is not clickable).
> I believe it makes sence to defer switching to different request target until finishing responding on ajax request.
> I found WebApplication.logResponseTarget(IRequestTarget target) as the place where I can actually apply deferred redirect. Please don't kill or make this method final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3010) RequestCycle.setResponsePage should
defer switching to BookmarkableRequestTarget until finishing responding to
currrent target
Posted by "Vladimir Kovalyuk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902335#action_12902335 ]
Vladimir Kovalyuk commented on WICKET-3010:
-------------------------------------------
JS works only for bookmarkable redirects. It doesn't seem to work for new Page() case which is sometimes better that parsing PageParameters.
I suggest revising it later because there are the other concerns. For instance one has always pass AjaxRequestTarget through all the methods in the call tree. Or for instance RequestCycle.getResponsePage will return subject of redirecting instead of the current page and one will always has to pass some Component in order to get the page from it. I believe WiQuery has many pitfalls around that.
Any guarantees on overriding WebApplication.logResponseTarget(IRequestTarget target)? Or am I missing the other Wicket request lifecycle callback methods?
> RequestCycle.setResponsePage should defer switching to BookmarkableRequestTarget until finishing responding to currrent target
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-3010
> URL: https://issues.apache.org/jira/browse/WICKET-3010
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.10
> Reporter: Vladimir Kovalyuk
> Assignee: Igor Vaynberg
>
> Once setResponsePage is called the AjaxRequestTarget is pushed down in the list of request targets and AjaxRequestTarget won't be called anymore because AbstractRequestCycleProcessor.respond invokes the current request target only.
> My page has some ajax links that delegates handling to different module and link does not know whether redirect happens. The link still has to update some components. But in case of redirect all the updates aren't applied and backbuttoning shows old state (actually with ajax indicator covering all the page so any element is not clickable).
> I believe it makes sence to defer switching to different request target until finishing responding on ajax request.
> I found WebApplication.logResponseTarget(IRequestTarget target) as the place where I can actually apply deferred redirect. Please don't kill or make this method final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-3010) RequestCycle.setResponsePage should
defer switching to BookmarkableRequestTarget until finishing responding to
currrent target
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-3010.
-----------------------------------
Assignee: Igor Vaynberg
Resolution: Won't Fix
this is a big time edge case, and i dont think we will support it.
an easy workaround is instead of calling setresponsepage append javascript to the target that will redirect.
> RequestCycle.setResponsePage should defer switching to BookmarkableRequestTarget until finishing responding to currrent target
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-3010
> URL: https://issues.apache.org/jira/browse/WICKET-3010
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.10
> Reporter: Vladimir Kovalyuk
> Assignee: Igor Vaynberg
>
> Once setResponsePage is called the AjaxRequestTarget is pushed down in the list of request targets and AjaxRequestTarget won't be called anymore because AbstractRequestCycleProcessor.respond invokes the current request target only.
> My page has some ajax links that delegates handling to different module and link does not know whether redirect happens. The link still has to update some components. But in case of redirect all the updates aren't applied and backbuttoning shows old state (actually with ajax indicator covering all the page so any element is not clickable).
> I believe it makes sence to defer switching to different request target until finishing responding on ajax request.
> I found WebApplication.logResponseTarget(IRequestTarget target) as the place where I can actually apply deferred redirect. Please don't kill or make this method final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-3010)
RequestCycle.setResponsePage should defer switching to
BookmarkableRequestTarget until finishing responding to currrent target
Posted by "Vladimir Kovalyuk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902335#action_12902335 ]
Vladimir Kovalyuk edited comment on WICKET-3010 at 8/25/10 3:58 AM:
--------------------------------------------------------------------
JS works only for bookmarkable redirects. It doesn't seem to work for new Page() case which is sometimes better that parsing PageParameters.
I suggest revising it later because there are the other concerns. For instance one has to pass AjaxRequestTarget through all the methods in the call tree. Or for instance RequestCycle.getResponsePage returns subject of redirecting instead of the current page and one will always have to pass some Component in order to get the page from it. I believe WiQuery has many pitfalls around that.
Any guarantees on overriding WebApplication.logResponseTarget(IRequestTarget target)? Or am I missing the other Wicket request lifecycle callback methods?
was (Author: vladimir.kovalyuk):
JS works only for bookmarkable redirects. It doesn't seem to work for new Page() case which is sometimes better that parsing PageParameters.
I suggest revising it later because there are the other concerns. For instance one has always pass AjaxRequestTarget through all the methods in the call tree. Or for instance RequestCycle.getResponsePage will return subject of redirecting instead of the current page and one will always has to pass some Component in order to get the page from it. I believe WiQuery has many pitfalls around that.
Any guarantees on overriding WebApplication.logResponseTarget(IRequestTarget target)? Or am I missing the other Wicket request lifecycle callback methods?
> RequestCycle.setResponsePage should defer switching to BookmarkableRequestTarget until finishing responding to currrent target
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-3010
> URL: https://issues.apache.org/jira/browse/WICKET-3010
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4.10
> Reporter: Vladimir Kovalyuk
> Assignee: Igor Vaynberg
>
> Once setResponsePage is called the AjaxRequestTarget is pushed down in the list of request targets and AjaxRequestTarget won't be called anymore because AbstractRequestCycleProcessor.respond invokes the current request target only.
> My page has some ajax links that delegates handling to different module and link does not know whether redirect happens. The link still has to update some components. But in case of redirect all the updates aren't applied and backbuttoning shows old state (actually with ajax indicator covering all the page so any element is not clickable).
> I believe it makes sence to defer switching to different request target until finishing responding on ajax request.
> I found WebApplication.logResponseTarget(IRequestTarget target) as the place where I can actually apply deferred redirect. Please don't kill or make this method final.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.