Having just run into a situation where I forgot to do an instanceof check on
PageExpiredException myself, I now agree that your interface is a good thing
to have.
Eelco
Jonathan Locke wrote:
>
>
> 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#a9722319
Sent from the Wicket - Dev mailing list archive at Nabble.com.
