You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Beyonder Unknown <be...@yahoo.com> on 2008/01/11 02:05:08 UTC
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: the flow of wicket
Posted by Dan Kaplan <dk...@citizenhawk.com>.
Sorry, I didn't know that it was internal implementation details. I see it
mentioned a lot so I supposed that it's very important to understand it in
order to use wicket correctly.
-----Original Message-----
From: Igor Vaynberg [mailto:igor.vaynberg@gmail.com]
Sent: Thursday, January 10, 2008 5:09 PM
To: users@wicket.apache.org
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 <dk...@citizenhawk.com> wrote:
> seconded
>
>
> -----Original Message-----
> From: Beyonder Unknown [mailto:beyonder_x@yahoo.com]
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: the flow of wicket
Posted by Dan Kaplan <dk...@citizenhawk.com>.
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:martijn.dashorst@gmail.com]
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 <pa...@gmail.com> 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 <ig...@gmail.com> 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 <dk...@citizenhawk.com> wrote:
> > > seconded
> > >
> > >
> > > -----Original Message-----
> > > From: Beyonder Unknown [mailto:beyonder_x@yahoo.com]
> > > 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <pa...@gmail.com> 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 <ig...@gmail.com> 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 <dk...@citizenhawk.com> wrote:
> > > seconded
> > >
> > >
> > > -----Original Message-----
> > > From: Beyonder Unknown [mailto:beyonder_x@yahoo.com]
> > > 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Advanced Technology® <th...@gmail.com>.
+1
On 1/12/08, Paolo Di Tommaso <pa...@gmail.com> 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 <ig...@gmail.com> 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 <dk...@citizenhawk.com> wrote:
> > > seconded
> > >
> > >
> > > -----Original Message-----
> > > From: Beyonder Unknown [mailto:beyonder_x@yahoo.com]
> > > 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
--
Sent from Gmail for mobile | mobile.google.com
AT(R)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Dmitry Kandalov <no...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Dmitry Kandalov <no...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
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.
-igor
On Jan 12, 2008 11:56 AM, Dmitry Kandalov <no...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Fabio Fioretti <wi...@gmail.com>.
On Jan 14, 2008 1:00 AM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Gwyn Evans <gw...@gmail.com>.
On 21/01/2008, Eelco Hillenius <ee...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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.
Thanks syl (whoever you are),
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Fabio Fioretti <wi...@gmail.com>.
On Jan 14, 2008 1:35 AM, Eelco Hillenius <ee...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Eelco Hillenius <ee...@gmail.com>.
> > 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
On Jan 13, 2008 3:28 PM, Fabio Fioretti <wi...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Fabio Fioretti <wi...@gmail.com>.
On Jan 12, 2008 8:56 PM, Dmitry Kandalov <no...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
On Jan 14, 2008 6:08 AM, Alex Jacoby <ae...@isr.umich.edu> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Alex Jacoby <ae...@isr.umich.edu>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Johan Compagner <jc...@gmail.com>.
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 <no...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Dmitry Kandalov <no...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
On Jan 12, 2008 11:11 AM, Dmitry Kandalov <no...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Dmitry Kandalov <no...@gmail.com>.
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
On Jan 12, 2008 7:16 AM, Paolo Di Tommaso <pa...@gmail.com> 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 <ig...@gmail.com> 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 <dk...@citizenhawk.com> wrote:
> > > seconded
> > >
> > >
> > > -----Original Message-----
> > > From: Beyonder Unknown [mailto:beyonder_x@yahoo.com]
> > > 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: the flow of wicket
Posted by David Leangen <wi...@leangen.net>.
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: the flow of wicket
Posted by Paolo Di Tommaso <pa...@gmail.com>.
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 <ig...@gmail.com> 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 <dk...@citizenhawk.com> wrote:
> > seconded
> >
> >
> > -----Original Message-----
> > From: Beyonder Unknown [mailto:beyonder_x@yahoo.com]
> > 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: the flow of wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <dk...@citizenhawk.com> wrote:
> seconded
>
>
> -----Original Message-----
> From: Beyonder Unknown [mailto:beyonder_x@yahoo.com]
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: the flow of wicket
Posted by Dan Kaplan <dk...@citizenhawk.com>.
seconded
-----Original Message-----
From: Beyonder Unknown [mailto:beyonder_x@yahoo.com]
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org