i think it's good the way it is. i'm loathe to narrow to a class here.
conceptually it's really the page you want to check against. not
necessarily
just the page's class.
Ryan Holmes wrote:
>
> Seems way too easy, but what about changing PageLink.linksTo(Page)
> from this:
>
> public boolean linksTo(final Page page)
> {
> return page.getClass() == pageLink.getPageIdentity();
> }
>
> to this:
>
> public boolean linksTo(final Class c)
> {
> return c == pageLink.getPageIdentity();
> }
>
>
> and changing Link.isEnabled() from this:
>
> public boolean isEnabled()
> {
> if (getAutoEnable())
> {
> return !linksTo(getPage());
> }
> return super.isEnabled();
> }
>
> to this:
> public boolean isEnabled()
> {
> if (getAutoEnable())
> {
> return !linksTo(getPage().getClass());
> }
> return super.isEnabled();
> }
>
> (based on 1.2.x)
>
> -Ryan
>
> On Feb 25, 2007, at 11:38 AM, Jonathan Locke wrote:
>
>>
>>
>> i don't think you really listened to me. the part i want is not
>> the delayed
>> creation of the page. you can get that by subclassing link. what
>> i want
>> for myself and all wicket users is the /identity/ part. without
>> that wicket
>> cannot disable self-referential links automatically. this makes
>> menuing
>> with links a hassle. if you can explain how i can do delayed
>> linking but
>> still
>> have wicket deal with disabling links to their containing page
>> automatically,
>> i'm fine with that. if not, i'm very much -1 on it.
>>
>>
>> igor.vaynberg wrote:
>>>
>>> why not let us remove it, and you copy it into your project
>>>
>>> -igor
>>>
>>>
>>> On 2/25/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>
>>>> i don't want to gang up on martijn here, but that's what i meant.
>>>> i also think we should refactor pagelink with the remaining two
>>>> constructors to:
>>>>
>>>> pageclasslink (the one with the class contructor)
>>>>
>>>> and
>>>>
>>>> delayedpagelink (the one with the ipagelink constructor)
>>>>
>>>> this way there is no class name pagelink (which is dangerous because
>>>> it's such an obvious name). this situation will make it very
>>>> obvious
>>>> what users ought to do (now Link is the most obvious class) and
>>>> pageclasslink
>>>> and delayedpagelink will both be slightly more efficient since
>>>> they won't
>>>> share an unused field. then users will have a choice between:
>>>>
>>>> link
>>>> pageclasslink
>>>> bookmarkablepagelink
>>>> delayedpagelink
>>>>
>>>> that seems like a very good situation.
>>>>
>>>> if you're still unhappy, martijn, maybe we could keep the page
>>>> constructor
>>>> in a deprecated class like pagereferencelink. that would help guide
>>>> users
>>>> away from the class, but it would still be there for backwards
>>>> compat.
>>>>
>>>> jon
>>>>
>>>>
>>>> Eelco Hillenius wrote:
>>>>>
>>>>>> Very convenient to hold a vote when I'm not around...
>>>>>
>>>>> It wasn't concluded yet. And the vote wasn't started because of
>>>>> your
>>>>> absence, but because of a message to the list.
>>>>>
>>>>> Martijn, the tricky situation here is that everyone on the team
>>>>> - and
>>>>> I'm pretty sure including the ones who didn't vote - is very much
>>>>> against having this constructor. VERY much. It leads to a dangerous
>>>>> situation and as a message earlier this week showed, people ARE
>>>>> using
>>>>> it the wrong way. God knows how many. This is not just a matter
>>>>> of not
>>>>> reading the docs for people, this is a matter of the API guiding in
>>>>> the wrong direction. Also, if documentation was enough, why think
>>>>> about API design in the first place? Also, comparing with
>>>>> methods that
>>>>> have the 'do not use this' warnings in them is just plain bs, as we
>>>>> have such 'constructs' because there was alternative to them,
>>>>> mainly
>>>>> because Java doesn't have a friends construction.
>>>>>
>>>>>> -1 on removing the constructor. Just as Jonathan...
>>>>>
>>>>> Great, another veto. Jonathan was against removing the class
>>>>> altogether (which I am personally +1 for, but not that strongly to
>>>>> make a lot of trouble). He stated he uses the IPageLink
>>>>> constructor a
>>>>> lot, while this vote is for removing the Page constructor.
>>>>>
>>>>> The only alternative I can see here is to leave the constructor
>>>>> in - a
>>>>> half baked solution which I would hate nevertheless - but put a
>>>>> @deprecated tag with a big fat warning in it.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Eelco
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/VOTE%3A-remove-PageLink%28String%2CPage%29-
>>>> constructor-tf3274259.html#a9145872
>>>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/VOTE%3A-remove-
>> PageLink%28String%2CPage%29-constructor-tf3274259.html#a9147112
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context:
http://www.nabble.com/VOTE%3A-remove-PageLink%28String%2CPage%29-constructor-tf3274259.html#a9149738
Sent from the Wicket - Dev mailing list archive at Nabble.com.
