if we're getting rid of PageLink entirely, you mean:
new Link(previousPage)
{
public void onClick() { setResponsePage(prevPage); }
public boolean linksTo(Page page) { return page.equals(prevPage); }
}
Johan Compagner wrote:
instead of doing this:
PageLink link = new
On 2/26/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
I see it as a pretty major api break. Considering that everyone on our
project uses the construct to return quickly to the previous page,
which is a very valid usecase. I can only imagine that many others
have used this construct as well.
I
And by example I mean: a document that is on our website, not
something in wicket-examples.
Martijn
On 2/25/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
Very convenient to hold a vote when I'm not around...
-1 on removing the constructor. Just as Jonathan, I have tons of code
that relies on
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
ok. i'll buy that for a dollar.
Eelco Hillenius wrote:
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
ok. i'll buy that for a dollar.
I'll get you the next coffee then ;)
Eelco
The class constructor is also a delayed creation.. just as the ipagelink..
I would just keep the PageLink with the 2 constructors..
(removing the Page constructor is fine with me but if it is veto's its also
fine. then just
update the doc with a big warning)
johan
On 2/25/07, Jonathan Locke
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)
{
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
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.
you are assuming that identity is only defined by the class. but what if
pageparameters/models are also involved?
then that code has to go somewhere anyways
-igor
On 2/25/07, Jonathan Locke [EMAIL PROTECTED] wrote:
let's just take a step back and ask: how can we make this less work?
Ok. As long as the page constructor goes. That one is too dangerous
and sweat starts breaking out all over when I think of the number of
people that may be mis-using this class already.
Eelco
On 2/23/07, Johan Compagner [EMAIL PROTECTED] wrote:
BookmarkableLink and PageLink are different
yes. i'm +1 on removing that constructor for user education purposes.
it's good to prevent innocent people from doing something naive here.
Eelco Hillenius wrote:
Ok. As long as the page constructor goes. That one is too dangerous
and sweat starts breaking out all over when I think of the
13 matches
Mail list logo
