You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2012/07/10 09:53:34 UTC

[jira] [Created] (WICKET-4647) Use NonResettingRestartResponseException for setResponsePage

Martin Grigorov created WICKET-4647:
---------------------------------------

             Summary: Use NonResettingRestartResponseException for setResponsePage
                 Key: WICKET-4647
                 URL: https://issues.apache.org/jira/browse/WICKET-4647
             Project: Wicket
          Issue Type: Improvement
          Components: wicket
    Affects Versions: 1.5.7
            Reporter: Martin Grigorov
            Assignee: Martin Grigorov
            Priority: Minor


WICKET-4636 made an improvement in Wicket rendering process by skipping the rendering of a page if there is a scheduled request handler after the current one.

A further optimization may be made by throwing NonResettingRestartResponseException from WICKET-4637 when setResponsePage() is used. This way even when setResponsePage() is during the rendering (e.g. in onBeforeRender()) Wicket will be able to stop the rendering and thus save some CPU cycles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (WICKET-4647) Use NonResettingRestartResponseException for setResponsePage

Posted by "Bertrand Guay-Paquet (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410356#comment-13410356 ] 

Bertrand Guay-Paquet commented on WICKET-4647:
----------------------------------------------

If setResponsePage() is modified to throw a NonResettingRestartResponseException, is there still a reason for it to exist at all? What was the original reason for its implementation instead of only using exceptions for issuing redirects? Since I had a closer look at the different ways to do redirects, I haven't been able to clearly understand the purpose of setResponsePage() in contrast to the exceptions (when NonResettingRestartResponseException is added to the set).

setResponsePage() is more complicated to implement and its behavior is less easily predictable than the exceptions'. Indeed, depending on where it's used, the current page will or will not be rendered, with all the side effects this can cause.

The one thing I can think of which setResponsePage() enables and the exceptions do not is overriding a previously set response page (cancelling a redirect or redirecting to another page). Example: myAbstractButton#onClick does setResponsePage() and myConcreteButton#onClick also does setResponsePage(). This can be implemented in another way, but as-is, it would break with exceptions.
                
> Use NonResettingRestartResponseException for setResponsePage
> ------------------------------------------------------------
>
>                 Key: WICKET-4647
>                 URL: https://issues.apache.org/jira/browse/WICKET-4647
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 1.5.7
>            Reporter: Martin Grigorov
>            Assignee: Martin Grigorov
>            Priority: Minor
>
> WICKET-4636 made an improvement in Wicket rendering process by skipping the rendering of a page if there is a scheduled request handler after the current one.
> A further optimization may be made by throwing NonResettingRestartResponseException from WICKET-4637 when setResponsePage() is used. This way even when setResponsePage() is during the rendering (e.g. in onBeforeRender()) Wicket will be able to stop the rendering and thus save some CPU cycles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (WICKET-4647) Use NonResettingRestartResponseException for setResponsePage

Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov resolved WICKET-4647.
-------------------------------------

    Resolution: Won't Fix

This improvement wont be applied for now because of the reasons pointed by Bertrand.
If someone needs such optimization then (s)he can throw one of the replacement exceptions instead of using setResponsePage()
                
> Use NonResettingRestartResponseException for setResponsePage
> ------------------------------------------------------------
>
>                 Key: WICKET-4647
>                 URL: https://issues.apache.org/jira/browse/WICKET-4647
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 1.5.7
>            Reporter: Martin Grigorov
>            Assignee: Martin Grigorov
>            Priority: Minor
>
> WICKET-4636 made an improvement in Wicket rendering process by skipping the rendering of a page if there is a scheduled request handler after the current one.
> A further optimization may be made by throwing NonResettingRestartResponseException from WICKET-4637 when setResponsePage() is used. This way even when setResponsePage() is during the rendering (e.g. in onBeforeRender()) Wicket will be able to stop the rendering and thus save some CPU cycles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (WICKET-4647) Use NonResettingRestartResponseException for setResponsePage

Posted by "Bertrand Guay-Paquet (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13415563#comment-13415563 ] 

Bertrand Guay-Paquet commented on WICKET-4647:
----------------------------------------------

After some more thought, I found another use case which would break by replacing setResponsePage() with an exception: in cases similar to WICKET-4575, where multiple methods participate in form handling, steps following the call to setResponsePage() in the chain would be skipped. This behavior would not at all be obvious or expected.
                
> Use NonResettingRestartResponseException for setResponsePage
> ------------------------------------------------------------
>
>                 Key: WICKET-4647
>                 URL: https://issues.apache.org/jira/browse/WICKET-4647
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 1.5.7
>            Reporter: Martin Grigorov
>            Assignee: Martin Grigorov
>            Priority: Minor
>
> WICKET-4636 made an improvement in Wicket rendering process by skipping the rendering of a page if there is a scheduled request handler after the current one.
> A further optimization may be made by throwing NonResettingRestartResponseException from WICKET-4637 when setResponsePage() is used. This way even when setResponsePage() is during the rendering (e.g. in onBeforeRender()) Wicket will be able to stop the rendering and thus save some CPU cycles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira