On Tue, Aug 5, 2014 at 2:21 PM, Yingshou Guo <[email protected]> wrote:
> 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? > There is a lot of room for improvement ! Any help is very welcome! > > 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. > The main problem is that the original author is not active since a long time. There was some documentation as comments between the if/elses in the code. But it was out of date so we improved the state by adding test cases and remove the obsolete comments. Next time someone changes something there the "living documentation" (the tests) will inform us right away. > > 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 > > > > > >
