I've read a lot of wicket source codes and this particular section is the only area that I cannot make any sense of. And I think this is one of the most important areas that may, with a thorough understanding, make me feel confident in my future projects using wicket. I'm not satisfied to just know how to use various kinds of components and how to composite some webpages. I hope to be able to contribute to wicket someday in the future. Anyway, the wicket project itself needs improvement, does not it?
I've read the jira you mentioned too. My impression is that as long as the maintainer/original developer confessed that the code is hairy, why not spending sometime time documents a little bit more and let's see if we can help out? It will save us a lot of time poking around and play guessing game. Regards, Guo Yingshou On Tue, Aug 5, 2014 at 7:14 PM, Martin Grigorov <[email protected]> wrote: > 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 > > >
