+1 On 1/12/08, 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. > > And I really don't understand in which way this could prevent you to change > - eventually - in future wicket versions. > > 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. > > 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. > > 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. > > 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] > > > > >
-- Sent from Gmail for mobile | mobile.google.com AT(R) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
