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.
