> 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
I know you don't. Neither do I, unless I can't find something
immediately. But that doesn't mean the rest of the world doesn't use
documentation. If they wouldn't, they wouldn't be bitching all the
time abt how much our documentation sucks :).
> 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.
Yeah, agreed. But not at the price of introducing spagethi.
Furthermore, a method in application like that doesn't give users any
idea about where such an exception is caught in the first place.
> 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.
I don't see your problem. We document it, give an example, and if
users are uncertain about what to use, they'll let us know. It really
isn't that much work. And in case they want to do logging or
something, it might even be much more elegant to proxy the default
processor. What are you doing now, putting all that dung in your
application class? Yech.
> 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.
Yeah, now *that's* a good question. Excactly. onRuntimeException will
not be called! How much does that suck?! That's my whole point of why
I don't think it should be in there.
> I just get a very nasty feeling about that.
Very nasty indeed :)
> CompoundRequestCycle is just the AWTEventDispatcher that Swing has for
> wicket. Nobody will reimplement that. But it will try to configure it right.
You don't know that. Probably nobody will reimplement
IRequestCycleProcessor, but you don't know. I first wanted to get an
interface - mostly for internal usuase - that captured exactly the
processing of a request cycle. I didn't specifically write it for
overriding, but the idea is layered, and people are free to do so if
they want. We can make it package private, but I don't see why we
should do that. Just so that we can support an 'easier' method in
application scope which don't give users any idea of how/ where it is
actually used?
Eelco
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
