On Jan 12, 2008 7:16 AM, Paolo Di Tommaso <[EMAIL PROTECTED]> wrote: > I disagree with this answer. > > The fact that request handling stuff is not a public api, is A GOOD REASON > because it should be documented better, not viceversa.
should we document how our xml parser works? how about how wicket assembles parts of markup into different markup fragments? all these things have no effect on you as a wicket user. a question for you, in what way will knowing the internal workflow of wicket request processing affect your programming decisions? > And I really don't understand in which way this could prevent you to change > - eventually - in future wicket versions. it takes away freedom. eg eelco and martijn thoroughly document this in their book about wicket 1.3. that means we cant change this significantly in at least 1.3 because we dont want leave people who bought the book to have the no longer valid idea. having no documentations for what we consider private parts allows us complete freedom. > I not a newbie user and I'm really a Wicket enthusiastic user and pleased to > be involved in its great community, but I have to admit that some topics are > still obscure. sure. thats why we have a wiki. > The request flow handling is one of the most important topic to know in a > web application framework, being so I think it would be very interesting to > have only a brief description, for example a sequence diagram showing the > components interaction starting from the WicketFilter (and/or the > WicketServlet) involved in a web request handling. Why is it so interesting? Do you know how the Valve workflow of tomcat works? Anyways, this has been on the wiki since October, maybe you guys need to learn how the search box works :) http://cwiki.apache.org/confluence/display/WICKET/Wicket+inside > > Hiding this stuff or, even worse, asking the users to debug the framework to > understand what it should important to know I don't think is a good approach > because it is precisely this that leads to wrong assumptions, that could > break in future. good, we want that freedom - to change it in the future. i dont see anything wrong with stepping through the code to learn how something works. that is pretty much how i learned all i know about wicket and i doubt i am that much smarter then you. -igor > > Thank you, > > - Paolo > > > > > On Jan 11, 2008 2:09 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > you guys want to know about internal implementation details. it has no > > publically exposed api, so why should you care? why should we document > > something that can change without affecting our users? does the jee > > spec detail how the request gets to the servlet? no, that is left up > > to the implementor of the servlet container. > > > > you want to know about it? set a break point in > > wicketfilter.dofilter() and walk the code. > > > > -igor > > > > > > On Jan 10, 2008 5:06 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > > > seconded > > > > > > > > > -----Original Message----- > > > From: Beyonder Unknown [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, January 10, 2008 5:05 PM > > > To: WICKET USER > > > Subject: the flow of wicket > > > > > > > > > Hi All, > > > > > > I am studying wicket from the WicketFilter to the WebApplication, but I > > > don't understand the concept of RequestCycleProcessor and how does it > > get > > > invoked. I read the "Wicket In Action" and "Pro Wicket" but the > > explanation > > > is not that detailed. Does anybody know of a primer with regards to how > > > Wicket process really works? I want to know the flow, from startup of > > the > > > servlet container, like what is being instantiated, and when request is > > > made. > > > > > > I can't seem to trace how RequestTarget being consumed by > > > RequestCycleProcessor, from the page. > > > > > > Thank you very much! > > > > > > Best, > > > Wen Tong > > > > > > -- > > > The only constant in life is change. > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________________ > > > ________ > > > Be a better friend, newshound, and > > > know-it-all with Yahoo! Mobile. Try it now. > > > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
