http://grepcode.com/file/repo1.maven.org/maven2/org.apache.wicket/wicket/1.4.2/org/apache/wicket/markup/html/link/BookmarkablePageLink.java#BookmarkablePageLink.getPageClass%28%29
-igor On Mon, Jan 18, 2010 at 8:36 AM, Jeroen Steenbeeke <j.steenbeeke...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
