Well, how can you tell that a page is an error page if you only have it’s class in your hands? AFAIK you need to check wether:
a) it’s a descendant of org.apache.wicket.markup.html.pages.AbstractErrorPage b) it’s a descendant of your own error page hierarchy, if any c) it is one of the classes (or subclasses) returned by: Application.get().getApplicationSettings().get[AccessDeniedPage|InternalErrorPage|PageExpiredErrorPage]() Or do you see an easier solution to this? In that usecase isErrorPage() always returns static values, so IMHO it would be safe to call it. Yes, but I also see your concerns of passing around not-yet-fully-initialized instances. Personally I’d prefer to pass them and document it accordingly as it means more freedom and flexibility. -Tom On 20.12.2013, at 10:32, Sven Meier <s...@meiers.net> wrote: > The reporter of the issue states that a "call to isErrorPage() would be more > elegant in that situation" > > If the passed instance is not yet fully constructed, how can #isErrorPage() > return anything useful other than static information? Isn't the class or any > of its annotations sufficient in this case? > > Sven > > On 12/20/2013 10:19 AM, Carl-Eric Menzel wrote: >> Duh. I knew I missed an obvious one! You are of course right. >> >> So we can't get rid of that one easily. That said, I'm still wary of >> spreading unfinished objects even further around the API. >> >> Carl-Eric >> >> On Fri, 20 Dec 2013 10:12:32 +0100 >> Sven Meier <s...@meiers.net> wrote: >> >>> SpringComponentInjector? >>> >>> Sven >>> >>> On 12/20/2013 10:09 AM, Carl-Eric Menzel wrote: >>>> I agree that something should be cleaned up. But like I said in the >>>> comment to that Jira ticket, I think it should in fact move more >>>> toward passing the class rather than the uninitialized instance. I >>>> like my objects to be predictable, and I like it even more when I >>>> don't have to think about any traps, even if they are >>>> well-documented. >>>> >>>> I think (I also wrote that in the comment) that perhaps >>>> IComponentInstantiationListener should be deprecated and eventually >>>> removed, since IComponentInitializationListener should be able to >>>> cover all the same use cases without having the unfinished >>>> constructor problem. >>>> >>>> Is there a use case that would not be handled by the initialization >>>> listener? >>>> >>>> Carl-Eric >>>> >>>> On Fri, 20 Dec 2013 10:53:40 +0200 >>>> Martin Grigorov <mgrigo...@apache.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> The reporter of https://issues.apache.org/jira/browse/WICKET-5454 >>>>> asked to pass the Component instance >>>>> to IAuthorizationStrategy#isInstantiationAuthorized() instead of >>>>> just its class. >>>>> I have no idea why the API has been designed this way but Carl-Eric >>>>> gave a good explanation - the component is not yet fully >>>>> constructed. >>>>> >>>>> The thing that bothers me is why it is OK to use the instance in my >>>>> custom IComponentInstantiationListener and it is not OK to do the >>>>> same in IAuthorizationStrategy#isInstantiationAuthorized() ? >>>>> If there is a javadoc explaining the possible problem (as for >>>>> IComponentInstantiationListener#onInstantiation()) then it is OK. >>>>> >>>>> Even more - at >>>>> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/Application.java#L276you >>>>> can see that right ater rejecting the *Class* we pass the >>>>> *instance* to >>>>> the UnauthorizedComponentInstantiationListener! >>>>> >>>>> >>>>> Martin Grigorov >>>>> Wicket Training and Consulting >
