Don't agree with that it is a documentation thing.
I almost never look at documenation at all. If you have to look at it to find out that you have
to do that hat and that to just do this then it is the fault of the API itself.
API itself should be readable. That is how i look at everything i do.

And i stick with it if i have to override X number of behaviour and that i do with this :

  protected IRequestCycleProcessor getDefaultRequestCycleProcessor()
 {
    return new CompoundRequestCycleProcessor(new WebRequestEncoder(),
new DefaultEventProcessorStrategy(), new MyExceptionProcessor();
 }

I just want to insert a new Exception processor, But i also suddenly override every other default thing wicket does!!
That is just plain wrong.

What happens if somebody build on top of my application class? And wants to do there own WenRequestEncoder() ?
Then suddenly it has to copy MY part of the default request processor and add theres. But that will not happen
i think i loose my Exception processor because he just override the default wickets and only change the webrequest encoder.

I just get a very nasty feeling about that.

CompoundRequestCycle is just the AWTEventDispatcher that Swing has for wicket. Nobody will reimplement that. But it will try to configure it right.



Reply via email to