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]

Reply via email to