I agree in principle, but there's a flaw in this reasoning. All exceptions
cannot
be handled in the same way in terms of Wicket's internals. For example, an
internal
error page really does have to be handled differently to protect against
recursive
exceptions. In my proposal, the user is insulated from all this. I think
it's probably
better to expose the minimal set of exceptions that the user can easily deal
with through factory methods like this. And I don't think we'll need more
factory
methods necessarily. The nice thing about the interface i proposed
is that it is actually completely general. There are special cases for a
couple
of the common exception types because they are logically different, but the
newExceptionErrorPage can handle every other case.
I think there's a balance here between generality (which as you point out we
already have in onRuntimeException) and real convenience for a very common
use case (which this interface would give us). So I hear you, but I still
think my
approach is pretty good for end users.
Eelco Hillenius wrote:
>
> 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.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Error-page-factory-tf3459831.html#a9655805
Sent from the Wicket - Dev mailing list archive at Nabble.com.
