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
> 

Reply via email to