On Mon, Mar 10, 2008 at 9:55 PM, James Carman
<[EMAIL PROTECTED]> wrote:
> 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?
im not a big fan of using threadlocals everywhere personally...we
guarantee certain ones, but they make unit testing, etc, a pita. i
would prefer passing the instance in.
> I hadn't thought of the root cause stuff, admittedly.
we, as core devs, try to think of all angles before adding something
like this into core :)
> However, just
> going up the main hierarchy is probably sufficient for a majority of
> use cases.
thats one data point. we would have to open this up to the community
before we make a decision though.
> 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.
ok. this is making more sense. so we would change Page
onRuntimeException(RT e) to ExceptionHandler onRuntimeException(RT e),
and the default resolution algorithm will be what most people agree on
as the best default. on the other hand, you can just override
requestcycle.onruntimeexception(rt e) {
map
handlers=beanfactoryutils.beansoftypeincludingancestors(applicationcontext,exceptionhandler.class);
for (excpetionhandler handler:handlers.values()) {
if (handler.matches(e)) { return e.getPage(e); break; }
}
return super.onruntimeexception(e);
}
that is about 5 lines of code and it doesnt force a specific algorithm
or exception handler onto the user...
> 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. :)
definately please do. we appreciate all the feedback. please dont take
me pushing back as a way to discourage you.
> Keeping the core framework
> "bare" is a good approach.
our api surface area is already pretty large, makes the framework
harder to learn. so we try to keep it as small as possible, that is
not to say we do not implement new ideas/features.
> 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.
i believe most, all that i have worked on, wicket application have
their own custom subclass of webrequestcycle, so a factory wouldnt
really benefit anyone if it's only purpose is to make installing a
generic subclass easier. what you can do is create your own subclass
of webrequestcycle that has handler registration, that way users can
subclass yours instead of webrequestcycle and get the handler
functionality. you can, for example, store registered handlers in
application metadata facility.
-igor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
