Because neither has a getPageClass() method? 2010/1/18 Igor Vaynberg <igor.vaynb...@gmail.com>: > 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 > >
-- Jeroen Steenbeeke www.fortuityframework.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
