On 3/11/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > you might also need access to the request cycle inside the > exceptionhandler, so thats three arguments now...maybe on exception > you want to set a 503 error > > also what is the search order for handler resolution? do we go root > cause->outer or outer->root cause? both can make sense in certain > situations which would make handler resolution ambiguous... > > we prefer to keep wicket bare and let users come up with their own > solutions for these sorts of thing, that work exactly how they want. >
The request cycle is easy enough to access anywhere, RequestCycle.get() right? I hadn't thought of the root cause stuff, admittedly. However, just going up the main hierarchy is probably sufficient for a majority of use cases. If a user needs more advanced search capability, I guess they could do it themselves. Maybe the search algorithm could be put in the RequestCycle class' onRuntimeException() method itself. Then, all you'd have to do is override Application.newRequestCycle() and RequestCycle.onRuntimeException() to plug in your own advanced handler search capability. I think this sort of feature is a common enough need that it could be built in, but that's just my opinion. I'm somewhat new to the Wicket community, so maybe I just didn't "get" the Wicket philosophy. That doesn't mean that I won't offer suggestions that I find useful anymore. :) Keeping the core framework "bare" is a good approach. Another thought I had is that inside the "new" methods on Application, maybe it could call a factory instead of doing the logic itself. Then, the factory could be configured by subclasses to override the default behavior rather than having to implement the method themselves. For instance, you could come up with a IRequestCycleFactory interface. So, if I were to write a little project that does what I want w.r.t. this exception handler stuff, all someone would have to do in their application is plug in my IRequestCycleFactory implementation to get that functionality. They wouldn't have to extend my Application superclass (what if they wanted to use another library which requires the extension of an Application superclass also?). The same sort of stuff could be done for Sessions, etc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
