There's a couple of things I'm not crazy about.

First of all, I'd much prefer just having factory method for
exceptions, so that clients can choose themselves what are interesting
exceptions and how to deal with that. That's way more flexible, as new
cases wouldn't need new methods, and it would keep the interface
minimal.

Another thing is that this would mean more ways to do the same thing.
We already have RequestCycle#onRuntimeException, which IMO is a decent
facility. I'd actually prefer it to be a bit more flexible to just
return a request target or something, so that you can send an error
code or redirect to a bookmarkable page (for the sake of ending up
with a better url).

I'm not saying RequesCycle#onRuntimeException is the ultimate solution
- though it suffices - but I do think we should try to get back to one
mechanism rather to extend to more options. What I currently like
about RequestCycle#onRuntimeException is that I feel it is the most
logical location for it: a request is being processed by the request
cycle, and something goes wrong... where would you look?

And in general, imo we could have less factory interfaces of any type
of favor of factory methods. ISessionFactory for instance could imo be
removed. It's good and clear we have that method in webapplication for
people to override, just like newSessionStore.

my 2c,

Eelco


On 3/24/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:


I posted this in response to a question on wicket-user and realized
this morning that I need to cross post this to wicket-dev since most
of it is about an RFE.

---

Perhaps in some near-future version, we can have an error
page factory.  I think that would be good because then you
don't need to get involved in the guts of Wicket to do something
pretty simple.  How about this:

    public interface IErrorPageFactory
    {
        Page newAccessDeniedPage(AuthorizationException e);
        Page newPageExpiredPage(PageExpiredException e);
        Page newExceptionErrorPage(RuntimeException e);
        Page newInternalErrorPage(RuntimeException e);
    }

then make a default implementation so people can override just the
pages they want to customize:

    public class AbstractErrorPageFactory implements IErrorPageFactory { ...
}

This would give users the ability to customize without the need to know
details like what's in

    AbstractRequestCycleProcessor.respond(RuntimeException e, RequestCycle
requestCycle)

most of which really is necessary to do handle exceptions right.

Maybe some developer on the core team would like to handle this?
If so, we could remove a number of annoyingly non-general settings
from ApplicationSettings in favor of just getErrorPageFactory()

--
View this message in context: 
http://www.nabble.com/Error-page-factory-tf3459831.html#a9653220
Sent from the Wicket - Dev mailing list archive at Nabble.com.


Reply via email to