On 3/11/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > 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'm not a big fan either. Adding a parameter isn't a bad idea, then.
> > 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);
> }
>
The change I was suggesting wouldn't break any existing code (unless
someone implemented IRequestCycleSettings). The signature of
RequestCycle.onRuntimeException() wouldn't change:
public Page onRuntimeException( Page page, RuntimeException e )
{
IRuntimeExceptionHandler handler = findBestExceptionHandler(e.getClass());
if(handler != null)
{
return handler.onRuntimeException(this, e);
}
return null;
}
protected IRuntimeExceptionHandler findBestExceptionHandler(Class
exceptionClass)
{
while(exceptionClass != null && !exceptionClass.equals(Exception.class))
{
IRuntimeExceptionHandler handler =
getApplication().getRequestCycleSettings().getRuntimeExceptionHandler(exceptionClass);
if(handler != null)
{
return handler;
}
exceptionClass = exceptionClass.getSuperclass();
}
return null;
}
This way, if the user wants to override the search algorithm, they can
override the findBestExceptionHandler() method. And, if they haven't
registered any handlers, then this method does exactly what it used to
do (nothing). Whatever the default algorithm would be of course is up
for debate. This is just simple example (and off the top of my head,
so if it really doesn't work as is, then sorry).
>
> 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.
>
Trust me, I know (about the hard to learn part)! I signed up to do a
talk on Wicket to our local Java users group (anyone in the
Cincinnati, OH area is free to join us next Monday) and it has now
turned into two talks: Introduction to Wicket and Advanced Wicket (May
2008)!
> 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.
Okay, so it's common to do your own request cycle implementation. I
didn't realize that. In Tapestry, RequestCycle wasn't something you
monkeyed around with much.
So, you're saying that I would store my exception handler "registry"
as metadata entries on the Application class? I would maybe store my
Map<Class,IRuntimeExceptionHandler>? What would the MetaDataKey be?
I just don't want to force users to subclass a custom WebApplication
class. I'd rather have the IRuntimeRequestHandlers registered with
IRequestCycleSettings (or the IExceptionSettings, maybe?).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
