I hate that i have to do so much for just implement one method to handle exceptions.
That is just to hard to know and to figure out because it is so hidden.
And it is not just a few lines of code but also doing stuff/reimplementing that is already done in wicket.
You have to write a very large line of code which is almost an exact copy of the default behaviour what wicket does.
And when you do that. You suddenly loose everything that wicket can or will change improve on that part.
As i said. That method can be gone but then i don't want to push developers to do new Compound... new WebEncoder.. new XXX , new YY and then they are on that point.
One last word about IExceptionResponseStrategy: that's an
implementation specific interface that is used by
AbstractCompoundRequestCycleProcessor and its inheriting classes. That
interface must *never* be part of a factory method in application
because who says you want to use AbstractCompoundRequestCycleProcessor
anyway.
So that interface should never be used outside wicket?
It is a pure internal interface?
Then it shouldn't be an interface at the first place. Just a class would do then...
If that is not the case then it is a part of wicket. It is a part of the implementation. And users should be able to easy create there own.
I think 99.9% of the users will never make there own IRequestCycleProcessor implementation.
They will all use the default one that Wicket provides and tweak that one and that tweaking should be easier then just have to override suddenly everything.
johan
