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
