Hi, May I ask you why you are interested exactly in this part of Wicket code ? Do you debug some problem or you are doing it just out of curiosity ?
https://github.com/apache/wicket/blob/wicket-1.5.x/wicket-core/src/main/java/org/apache/wicket/request/handler/render/WebPageRenderer.java#L164 points to https://issues.apache.org/jira/browse/WICKET-3347. We know that this part of the code is complex and we tried to simplify it a bit, but it is still hairy as the comment few lines below L164 says. The unit tests try to cover as much as possible paths... About getPage() calls - check with git blame when a particular call has been introduced, the commit message, the ticket description and the new unit test for it. This is what I do when I need to find such things. And just like you I also ask here in dev@ about such things :-) Have fun! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Tue, Aug 5, 2014 at 1:00 PM, Yingshou Guo <[email protected]> wrote: > Hi Martin, > > Thanks for your response, though I'm still as confused as before after > reading your answers several times. I've subscribed to the mailing list but > I have not received your response in my gmail box and I don't know how to > reply to your message. I should say sorry if this mail start in a new > thread. > > I know that there are three redirect policies and three rendering > strategies, the effect of the respond method inside WebPageRender is to > render a page corresponding to a specific http request taking into > considerations of all the possible combinations. By carefully inspecting > the code of shouldRenderPageAndWriteResponse and shouldRedirectToTargetUrl, > getPage() should have already been called earlier in isPageStateless(), > then why a standalone getPage() is invoked again? Looks like that it will > cause some global state to change? The only state change I can find is an > IRequestablePage instance in PageProvider will be retrieved from page store > or constructed afresh. Futher more, a getPage method is already defined in > RenderPageRequestHandler, why not make renderPageRequestHandler property > protected in PageRenderer instead of private? IMHO, if the > renderPageRequestHandler property is protected, there is no need to provide > a protected getRenderPageRequestHandler and a wrapper getPage method in the > PageRenderer. > > Sorry if the above questions do not make any sense as I am still in > confusion trying to understand the workflow of rendering a page. I'll spend > more time digesting the testcases. I'm switching to wicket after years of > web application development using springmvc. I hope that someday I can > contribute back to this project. > > Best, > > Guo Yingshou >
