Just committed an improved version. I think it is much better now.
Instead of having to pass objects in the constructor, you can now
override factory methods, while the compound processor still caches
it's delegates. Furthermore, there is really one delegate for which
there is no protocol agnostic implementation; RequestEncoder. I
created DefaultWebRequestCycleProcessor that passes in the right
encoder for web applications, WebRequestEncoder.

Abt onRuntimeException. I moved that method to RequestCycle.
RequestCycle.onRuntimeException is now called by
DefaultExceptionResponseProcessor. As the javadoc states at various
spots, you have to know what you are doing when you override the
processor, but as there is onRuntimeException in RequestCycle, there
is less need to do so, and /if/ you know what you are donig you can
still do so.

Eelco

On 12/19/05, Christian Essl <[EMAIL PROTECTED]> wrote:
> I am no develper. Anyway:
>
> Maybe you could use a simple service-registry, where one can register ie a
> RuntimeExceptionHandler and anyone else needing it can look it up? Similar
> to ApplicationSettings but takes interfaces.
>
> Christian
>
> On Mon, 19 Dec 2005 17:35:23 +0100, Eelco Hillenius
> <[EMAIL PROTECTED]> wrote:
>
> > What about some other pattern than just a factory method? Any of the
> > other devs care for this discussion?
> >
> > Eelco
> >
> > On 12/19/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >>
> >> > > 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.
> >>
> >>
> >> Ahh yes Exactly right!  I have implemenented my own
> >> DefaultExceptionResponseProcessor in my application object
> >> And i had to do this by overriding the IRequestCycleProcessor
> >> getDefaultRequestCycleProcessor() so now i have my neath
> >> exeption handler. But then suddenly somebody extends my application
> >> object
> >> and he wants its own Encoder and also overrides
> >> IRequestCycleProcessor getDefaultRequestCycleProcessor().
> >> HEE suddenly i loose Mine.
> >>
> >> So it is exactly the same!! Youre argument is exactly what i was
> >> constantly
> >> talking about.
> >> You should never need to override One method that does X number of
> >> things to
> >> do really override one thing!!
> >>
> >> I agree that maybe it is better that we don't have that onException
> >> method
> >> inside Application. Fine by me
> >> But not in the solution where you have to override completely something
> >> else
> >> at the first place to gain it.
> >>
> >> johan
> >>
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > 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
>
>
>
> --
> Christian Essl
>
>
>
> ___________________________________________________________
> Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
>
>
>
> -------------------------------------------------------
> 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_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>


-------------------------------------------------------
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

Reply via email to