Re: the flow of wicket
On 21/01/2008, Eelco Hillenius [EMAIL PROTECTED] wrote: Fine, this can be a good compromise: documentation written by the skilled community and reviewed by the developers themselves. I'm not that hardcore now, but the more I get into Wicket, the more I'll try to help out as much as I can. I just came across http://cwiki.apache.org/WICKET/wicket-inside.html and - though I just skimmed through it quickly - it seems that someone (syl?) already made quite an effort explaining how Wicket works internally. Pretty cool, and hopefully this will help people in this thread who were looking for a more high level (compared to javadocs and your debugger) explanation. Please, take those documents as your starting point and improve/ ask specific questions when you work through them. While I'd uploaded Dmitry's diagrams, they'd not got replicated through to the static site until the page was re-edited. I've just done so, to trigger the copy, so if you looked at the pages saw missing diagrams, please take another look! Thanks syl (whoever you are), Dmitry Kandalov, take a bow! /Gwyn -- Download Wicket 1.3.0 now! - http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 14, 2008 1:35 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: Documenting Wicket's inner implementations and strategies, beyond its API, is desirable and a huge plus for hardcore developers. i wouldnt think hardcore developers would be afraid of setting a breakpoint and walking the code. maybe one of them could even create a wiki page - open source and all that. Yup. Please anyone, take the initiative and write a WIKI page. That's more constructive than complaining about it here :-) Good if it is done by someone outside anyway, because that someone won't make the assumptions we probably would make. We'll be happy to review. Fine, this can be a good compromise: documentation written by the skilled community and reviewed by the developers themselves. I'm not that hardcore now, but the more I get into Wicket, the more I'll try to help out as much as I can. Thanks, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 14, 2008 1:00 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: easy to say when its not you who has to put in the huge effort :) I'm just a humble junior developer. :) Regards, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 12, 2008, at 2:56 PM, Dmitry Kandalov wrote: On Saturday 12 January 2008 23:25:43 Igor Vaynberg wrote: sure, and all you need to know is that you subclass requestcycle.onbeginrequest() and add your own code there and it is called at the beginning of the request. why do you need to know the sequence of calls that leads to onbeginrequest() being called? I don't. I can image someone may want to be sure that this method is called before anything else he overrides, or to know that he can't get requested page at this step, but probably it's a very rare case. I've hit exactly this type of issue -- you try to override one of the public methods, and it turns out that the object isn't fully initialized yet, so you can't do what you'd hoped to. I agree there's value to the black-box model, data encapsulation, and all that -- I don't want to know all the gory details of your implementation. However, for public methods which are designed to be overridden when necessary, it would be extremely helpful to have more documentation provided about the state of the object when that method is called. It's a matter of balance -- overall I think the documentation is pretty good, but there are places where it's weaker than it should be. Yes, I can set breakpoints and step through the code, but that shouldn't be the default response to questions about missing documentation. Following that argument you could say that NO javadocs are ever necessary :) Thanks for all the great work, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 14, 2008 6:08 AM, Alex Jacoby [EMAIL PROTECTED] wrote: I've hit exactly this type of issue -- you try to override one of the public methods, and it turns out that the object isn't fully initialized yet, so you can't do what you'd hoped to. do you have the example so we can do something to improve this? It's a matter of balance -- overall I think the documentation is pretty good, but there are places where it's weaker than it should be. Yes, I can set breakpoints and step through the code, but that shouldn't be the default response to questions about missing documentation. Following that argument you could say that NO javadocs are ever necessary :) ha. browse the archives or lurk on this list for a while, you will see that this is an extremely seldom response from the wicket team. -igor Thanks for all the great work, Alex - 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]
RE: the flow of wicket
I agree with this. When I seconded earlier, it was because I thought this was an exposed part of the API that hadn't been documented. I didn't realize it was internal. -Original Message- From: Martijn Dashorst [mailto:[EMAIL PROTECTED] Sent: Saturday, January 12, 2008 7:57 AM To: users@wicket.apache.org Subject: Re: the flow of wicket I *strongly* disagree with your answer. The fact is that this information is only beneficial for a really very small portion of our user base. The documentation effort on the other hand is HUGE! And subject to change easily. From 1.1 to 1.2 we changed it quite considerably. And I have no doubt this will change again. I posit that 99% of all developers working on Wicket applications don't need to know this. In my company we have about 30 people working on wicket applications and I think 29 of them don't even know the different request targets. Why would they? There is no benefit in learning what the request cycle processor does in its 30 odd steps when your customer asks for a link that adds an item to a shopping cart. In fact it makes it more difficult to achieve your business goals. Asking the remaining 1% to do some homework themselves gives us the possibility to work on actual code, improving the framework and making things simpler, better, easier, faster, completer. Martijn On Jan 12, 2008 4:16 PM, 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] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e
Re: the flow of wicket
On Sunday 13 January 2008 04:19:30 Igor Vaynberg wrote: Ok, so rarely you need to roll your own IRequestTargetUrlCodingStrategy, we do provide implementations to cover most common cases. And even if you do, you only need to know about IRequestTarget - which has good javadoc, and so does the coding strategy. You dont need to know anything about the irequestcycleprocessor, in fact it might even go away at a later release. May be it's just me but I didn't get how to use IRequestTargetUrlCodingStrategy after reading javadocs (I don't say they're bad). Though you're right request processor is not that important in this case, probably WebRequestCodingStrategy is. Anyway if you do something not very straightforward it may be quite useful to know at least something about the context in which your code is called. Coming back to onBeginRequest() I think it's not obvious to user whether he can use in it application, request, response or session object unless he knows workflow. If request cycle processor goes away I'm sure you'll do it right. I liked the way wicket changed from 1.2 to 1.3. Dima - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Sunday 13 January 2008 12:47:44 Dmitry Kandalov wrote: On Sunday 13 January 2008 04:19:30 Igor Vaynberg wrote: Ok, so rarely you need to roll your own IRequestTargetUrlCodingStrategy, we do provide implementations to cover most common cases. And even if you do, you only need to know about IRequestTarget - which has good javadoc, and so does the coding strategy. You dont need to know anything about the irequestcycleprocessor, in fact it might even go away at a later release. If request cycle processor goes away I'm sure you'll do it right. I liked the way wicket changed from 1.2 to 1.3. Ah.. sorry it wasn't relevant to what you said. Dima - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 12, 2008 8:56 PM, Dmitry Kandalov [EMAIL PROTECTED] wrote: On the whole I think it's the matter of knowing the big picture and not using framework as a black box. Exactly. For knowledge's sake. Documenting Wicket's inner implementations and strategies, beyond its API, is desirable and a huge plus for hardcore developers. Sure, we could study the code, but it can lead to bad assumptions if it's not coupled with some sort of high-level, even gross-grained, documentation. So, +1 for Paolo, even if I understand that the documentation effort can become huge. Cheers, Fabio Fioretti - WindoM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 13, 2008 3:28 PM, Fabio Fioretti [EMAIL PROTECTED] wrote: Documenting Wicket's inner implementations and strategies, beyond its API, is desirable and a huge plus for hardcore developers. i wouldnt think hardcore developers would be afraid of setting a breakpoint and walking the code. maybe one of them could even create a wiki page - open source and all that. So, +1 for Paolo, even if I understand that the documentation effort can become huge. easy to say when its not you who has to put in the huge effort :) -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
Documenting Wicket's inner implementations and strategies, beyond its API, is desirable and a huge plus for hardcore developers. i wouldnt think hardcore developers would be afraid of setting a breakpoint and walking the code. maybe one of them could even create a wiki page - open source and all that. Yup. Please anyone, take the initiative and write a WIKI page. That's more constructive than complaining about it here :-) Good if it is done by someone outside anyway, because that someone won't make the assumptions we probably would make. We'll be happy to review. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: the flow of wicket
It would be faster if you can help us. :) sure, it would probably be faster if i coded your project for you too :) Cool! Since you're now doing this kind of volunteer work, Igor, how about coding some stuff for me, too? ;-) I'll send you the project description off-link, but you need to sign an NDA first. It's only 67 pages long. only 67? :) Well, I didn't want to say 69, because then everybody would know what kinds of thoughts dominate my warped mind. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
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]
Re: the flow of wicket
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]
Re: the flow of wicket
I *strongly* disagree with your answer. The fact is that this information is only beneficial for a really very small portion of our user base. The documentation effort on the other hand is HUGE! And subject to change easily. From 1.1 to 1.2 we changed it quite considerably. And I have no doubt this will change again. I posit that 99% of all developers working on Wicket applications don't need to know this. In my company we have about 30 people working on wicket applications and I think 29 of them don't even know the different request targets. Why would they? There is no benefit in learning what the request cycle processor does in its 30 odd steps when your customer asks for a link that adds an item to a shopping cart. In fact it makes it more difficult to achieve your business goals. Asking the remaining 1% to do some homework themselves gives us the possibility to work on actual code, improving the framework and making things simpler, better, easier, faster, completer. Martijn On Jan 12, 2008 4:16 PM, 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] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
+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]
Re: the flow of wicket
On Saturday 12 January 2008 19:56:41 Igor Vaynberg wrote: 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? I mostly agree but request processing is more exposed to user than xml parser. I mean it's easier to came across AjaxRequestTarget, RequestCycle#onBegin/EndRequest() or mounting method for IRequestTargetUrlCodingStrategy than IXmlPullParser. 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. IMHO it would be possible to have a chapter on the topic with warning that content is relevant only for specific version of Wicket and may be changed in the future. 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 I'm changing it and at the moment it doesn't have some of the pictures. They'll be there with text updates in a couple of days. Dima - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Jan 12, 2008 11:11 AM, Dmitry Kandalov [EMAIL PROTECTED] wrote: On Saturday 12 January 2008 19:56:41 Igor Vaynberg wrote: I mostly agree but request processing is more exposed to user than xml parser. I mean it's easier to came across AjaxRequestTarget, RequestCycle#onBegin/EndRequest() or mounting method for IRequestTargetUrlCodingStrategy than IXmlPullParser. sure, and all you need to know is that you subclass requestcycle.onbeginrequest() and add your own code there and it is called at the beginning of the request. why do you need to know the sequence of calls that leads to onbeginrequest() being called? -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
On Saturday 12 January 2008 23:25:43 Igor Vaynberg wrote: sure, and all you need to know is that you subclass requestcycle.onbeginrequest() and add your own code there and it is called at the beginning of the request. why do you need to know the sequence of calls that leads to onbeginrequest() being called? I don't. I can image someone may want to be sure that this method is called before anything else he overrides, or to know that he can't get requested page at this step, but probably it's a very rare case. Though creating things like IRequestTargetUrlCodingStrategy requires knowledge about targets and request processor. On the whole I think it's the matter of knowing the big picture and not using framework as a black box. I don't mean everyone should do it. Dima - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
As far as i know there are some things on the wiki that explains what hooks (onXxx) is called when. And for the public methods this is fine and that should be documented, but still the rest should remain a black box as much as possibe On 1/12/08, Dmitry Kandalov [EMAIL PROTECTED] wrote: On Saturday 12 January 2008 23:25:43 Igor Vaynberg wrote: sure, and all you need to know is that you subclass requestcycle.onbeginrequest() and add your own code there and it is called at the beginning of the request. why do you need to know the sequence of calls that leads to onbeginrequest() being called? I don't. I can image someone may want to be sure that this method is called before anything else he overrides, or to know that he can't get requested page at this step, but probably it's a very rare case. Though creating things like IRequestTargetUrlCodingStrategy requires knowledge about targets and request processor. On the whole I think it's the matter of knowing the big picture and not using framework as a black box. I don't mean everyone should do it. Dima - 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]
RE: the flow of wicket
I disagree with this answer. That's great! You are most welcome to disagree. I happen to disagree with your disagreement. That's the great thing about OSS... If you disagree strongly enough, then maybe you can write more stuff on the wiki. I think you're missing a good opportunity here: look through the code and figure out as much as you can. When you get stuck, _then_ you can ask questions. Expecting documentation for that kind of internal stuff is the passive and easy way out. It takes a little more time (for you) than just reading doc, but it's not all that bad to just set break points and see what happens. I'm sure you'll catch on very quickly. Good luck! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: the flow of wicket
It would be faster if you can help us. :) sure, it would probably be faster if i coded your project for you too :) Cool! Since you're now doing this kind of volunteer work, Igor, how about coding some stuff for me, too? ;-) I'll send you the project description off-link, but you need to sign an NDA first. It's only 67 pages long. Thanks! Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: the flow of wicket
only 67? :) -igor On Jan 11, 2008 9:34 PM, David Leangen [EMAIL PROTECTED] wrote: It would be faster if you can help us. :) sure, it would probably be faster if i coded your project for you too :) Cool! Since you're now doing this kind of volunteer work, Igor, how about coding some stuff for me, too? ;-) I'll send you the project description off-link, but you need to sign an NDA first. It's only 67 pages long. Thanks! Dave - 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]
RE: the flow of wicket
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]
Re: the flow of wicket
Thanks for the info, Igor. I'll definitely attached the code and trace it from doGet(). Best, Wen Tong -- The only constant in life is change. - Original Message From: Igor Vaynberg [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Thursday, January 10, 2008 5:55:13 PM Subject: Re: the flow of wicket On Jan 10, 2008 5:47 PM, Beyonder Unknown [EMAIL PROTECTED] wrote: Hi Igor, Since it got mentioned in the book, I just thought I'd asked for more information. IRequestCycleProcessor has javadoc which explains what it is used for. the actual workflow is unimportant for newbies. if you really do care about it then set the breakpoint and walk it. I was also wondering how does it differ from the traditional model 2 MVC like struts, spring-mvc, etc. what is it? if it is wicket then the two major differences is that in wicket each instance of component acts as MVC, so a page MVC is made up of a bunch of other smaller MVCs. the second biggest difference is that wicket maintains the state of each of these MVCs for you so you dont have to manually encode it in url/post params... I tried adding breakpoints, but I lack the source. I guess i have to attached it in my eclipse. the source is out there, not that hard to get it or attach it. It would be faster if you can help us. :) sure, it would probably be faster if i coded your project for you too :) -igor Thanks, Wen Tong -- The only constant in life is change. - Original Message From: Igor Vaynberg [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Thursday, January 10, 2008 5:09:00 PM Subject: Re: the flow of wicket 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] Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping - 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] Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
