you meant page.getClass().equals(MyAccountPage.class)
that's quite a mouthful to repeat. it makes something you
don't care about but which i do all the time hard. just
because it's more minimal doesn't make it better.
i want more abbreviated support for auto-disabling of links
in the core. extracting a subclass of Link like AutoDisableLink
would be fine. but i don't really want to write the code below
by default and i think other users deserve the benefit of this
behavior by default too. it's how wicket makes link menus trivial
and users should not have to go hunting on the wiki to figure
it out.
igor.vaynberg wrote:
>
> add( new link("foo") {
> onclick() { setresponsepage(new MyAccountPage()); }
> boolean linksto(Page page) { return
> page.class.equals(MyAccountPage.class);
> }
> }
>
> simple as that and the bookmarkablepagelink already also does this
>
> -igor
>
>
> On 2/25/07, Jonathan Locke <[EMAIL PROTECTED]> 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#a9149710
Sent from the Wicket - Dev mailing list archive at Nabble.com.
