I totally agree with Jeroen. The 3rd constructor is dangerous and should be removed. The other two, however, are lazy and create the page in the onClick (provided that the IPageLink interface is implemented correctly). Of course, it is possible to copy PageLink and IPageLink to wicket-security, but that would be a large API-incompatible change, for which I see no compelling reason.
Emond On Monday 18 January 2010 08:44:28 Jeroen Steenbeeke 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. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
