Answers below.
On 12/19/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
> Then we really don't agree on this.
> 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.
That's more a case of faulty documentation than a faulty API.
> 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.
And like I said, I think it was wrong to put it there in the first
place. I understand why it was put there, but in hind sight,
RequestCycle would have been a much better/ obvious place. And *if* it
would have been part of RequestCycle, it would have been much more
logical to keep on supporting it after the refactorings as the scoping
still would be the same.
> 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.
You assume they have a problem with that. I don't think they have when
it is clearly documented. Furthermore, it would make them aware of
IRequestCycleProcessor with the added effect that they would
understand better how the request cycle works and how they can extend
its behaviour. Because then, it is all in the same place.
> > One last word about IExceptionResponseStrategy: that's an
> > implementation specific interface
>
>
> 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...
No, you can use that interface just fine. But you have to use it with
AbstractCompoundRequestCycleProcessor. However, as we don't know
whether that is used, or whether a user uses his own version of
IRequestCycleProcessor, we shouldn't put any dependency on it in the
Application.
>
> 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.
They can. Simple as in:
protected IRequestCycleProcessor getDefaultRequestCycleProcessor()
{
return new CompoundRequestCycleProcessor(new WebRequestEncoder(),
new DefaultEventProcessorStrategy(), new MyExceptionProcessor();
}
Don't tell me that is too difficult. Yes, they will have to know about
the RequestCycleProcessor in the first place, but again, that a matter
of documentation and it is a good idea to know about this anyway.
> 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.
Agreed. That's why I took the layered approach of first having the
base interface IRequestCycleProcessor, and secondly, to make things
easier pluggable, AbstractCompoundRequestCycleProcessor and it's
interfaces.
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
