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
