That's what I'm trying to say: it can't be accomplished by either BookmarkablePageLink or Link. Link does not have a getPageIdentity method and BookmarkablePageLink only works for bookmarkable links (duh). So Link is never an option because of the missing getPageIdentity method and BookmarkablePageLink only works for bookmarkable pages. What about links to pages that are not bookmarkable?
Emond On Monday 18 January 2010 17:12:49 Igor Vaynberg wrote: > well, if the functionality can be accomplished using either > BookmarkablePageLink or Link, why do we need yet another way to do it? > > -igor > > On Sun, Jan 17, 2010 at 11:44 PM, Jeroen Steenbeeke > > <j.steenbeeke...@gmail.com> wrote: > > Guys, no need to keep explaining what's wrong with passing a Page in > > the constructor, we understand that! > > > > Forget about that filthy 3rd constructor, I know it's wrong and I > > never used it anyway. That wasn't what my question was about. > > > > There are two more constructors: > > > > PageLink(String, Class) > > PageLink(String, IPageLink) > > > > Both of these do not replicate the dangerous behavior illustrated in > > this thread so far. I understand that we can easily create our own > > implementation that simulates the behavior we want. I just wanted to > > understand the reasoning for removing the whole class when only one of > > the constructors is dangerous. From what Martijn Dashorst just told > > me, it was a case of "seeing as we already have Link and > > BookmarkablePageLink, we figured you could just use those instead". > > > > This is also the source of miscommunication so far. The Javadoc simply > > states what you should use instead, but does not explicitly state why. > > The assumption is that any behavior you can achieve with the > > PageLink/IPageLink combination can also be done with a simple Link. > > This does not take into account the use of the Page Identity for > > security checks however (mainly for determining link visibility, > > which, frankly, does not need an actual instance of the page in > > question), which brings us back to Emond's original point. > > > > On the other hand, one could argue that the only use for the page > > identity is for security purposes, and it would therefore be more at > > home in a specialized class in wicket-security. > > > > -- > > Jeroen Steenbeeke > > www.fortuityframework.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
