Re: PageLink deprecated
But leaving IPageLink without any classes using it seems a bit weird to me. I think IPageLink should be removed with PageLink and probably be moved to wicket-security. On Tuesday 19 January 2010 11:36:59 Jeroen Steenbeeke wrote: > Which is what I suggested earlier in this discussion as well. So long > as nobody touches the IPageLink interface then simply adapting > SecurePageLink to use IPageLink directly would work without any > significant break in SecurePageLink's API. That way there are no icky > constructors and no unnecessary link classes. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageLink deprecated
Which is what I suggested earlier in this discussion as well. So long as nobody touches the IPageLink interface then simply adapting SecurePageLink to use IPageLink directly would work without any significant break in SecurePageLink's API. That way there are no icky constructors and no unnecessary link classes. -- Jeroen Steenbeeke www.fortuityframework.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageLink deprecated
This discussion is relevant: http://markmail.org/message/rwqrnvraoypwgbsj In that discussion Maurice opted for removing PageLink altogether and securing its functionality in SecurePageLink inside Wicket Security. I guess that is a good option. Martijn On Tue, Jan 19, 2010 at 9:04 AM, Igor Vaynberg wrote: > for nonbookmarkables you can use Link and simply override > equals/hashcode to create the pageidentity > > -igor > > On Mon, Jan 18, 2010 at 11:39 PM, Emond Papegaaij > wrote: >> 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 >>> >>> 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 >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageLink deprecated
for nonbookmarkables you can use Link and simply override equals/hashcode to create the pageidentity -igor On Mon, Jan 18, 2010 at 11:39 PM, Emond Papegaaij wrote: > 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 >> >> 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 > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageLink deprecated
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 > > 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
Re: PageLink deprecated
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 wrote: > Because neither has a getPageClass() method? > > 2010/1/18 Igor Vaynberg : >> 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 >> 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
Re: PageLink deprecated
Because neither has a getPageClass() method? 2010/1/18 Igor Vaynberg : > 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 > 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
Re: PageLink deprecated
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 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
Re: PageLink deprecated
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
Re: PageLink deprecated
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
Re: PageLink deprecated
Agreed. This stuff isn't rocket science. Look at the code. If you want to keep it around, write your own and use that. That's one of the nice things about Wicket; it makes it very easy to do stuff like this On Jan 15, 2010 3:05 AM, "Jeroen Steenbeeke" wrote: The obvious answer is to rewrite SecurePageLink to extend Link and take an IPageLink as parameter. IPageLink is not deprecated so I would hope that no trigger happy Wicket devs will be removing it. A quick look at the SVN trunk shows it is still available whereas PageLink is already gone. Then again, I am also curious as to why PageLink was deprecated in the first place. -- Jeroen Steenbeeke www.fortuityframework.com - To unsubscribe, e-mail: users...
Re: PageLink deprecated
Emond Papegaaij schrieb: We just found that PageLink has been deprecated in wicket 1.4. Can someone explain why? http://www.codesmell.org/blog/2009/01/pagelink-considered-harmful/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageLink deprecated
Jeremy, That does not explain why the whole class is deprecated. Getting rid of the constructor you linked to is a good thing, but why get rid of the whole class when using an IPageLink is really just an indirection to overriding onClick (with the added benefit of being able to use the page identity for security checks). 2010/1/16 Jeremy Thomerson : > Gone because creating the page(s) during the rendering of another page is a > bad idea. It should be done in the onClick handler. See the comment in the > deprecation note (of the method, not just the class). > > http://fisheye6.atlassian.com/browse/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/link/PageLink.java?r=814819#l122 > > -- > Jeremy Thomerson > http://www.wickettraining.com > -- Jeroen Steenbeeke www.fortuityframework.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageLink deprecated
Gone because creating the page(s) during the rendering of another page is a bad idea. It should be done in the onClick handler. See the comment in the deprecation note (of the method, not just the class). http://fisheye6.atlassian.com/browse/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/link/PageLink.java?r=814819#l122 -- Jeremy Thomerson http://www.wickettraining.com On Fri, Jan 15, 2010 at 2:04 AM, Jeroen Steenbeeke wrote: > The obvious answer is to rewrite SecurePageLink to extend Link and > take an IPageLink as parameter. IPageLink is not deprecated so I would > hope that no trigger happy Wicket devs will be removing it. A quick > look at the SVN trunk shows it is still available whereas PageLink is > already gone. > > Then again, I am also curious as to why PageLink was deprecated in the > first place. > > -- > Jeroen Steenbeeke > www.fortuityframework.com > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: PageLink deprecated
The obvious answer is to rewrite SecurePageLink to extend Link and take an IPageLink as parameter. IPageLink is not deprecated so I would hope that no trigger happy Wicket devs will be removing it. A quick look at the SVN trunk shows it is still available whereas PageLink is already gone. Then again, I am also curious as to why PageLink was deprecated in the first place. -- Jeroen Steenbeeke www.fortuityframework.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageLink deprecated
The javadoc says I should use Link or BookmarkablePageLink, which, as I explained, are both not an option. Emond On Friday 15 January 2010 05:08:42 Igor Vaynberg wrote: > what does the javadoc say? > > -igor > > On Thu, Jan 14, 2010 at 6:12 AM, Emond Papegaaij > > wrote: > > Hi, > > > > We just found that PageLink has been deprecated in wicket 1.4. Can > > someone explain why? I see no reason why PageLink should not be used. > > PageLink is the base for SecurePageLink (in wicket-security), which uses > > getPageIdentity for its security check. Using Link is not an option > > because it does not provide the page identity, and using > > BookmarkablePageLink is not an option because in many cases the target > > page is not bookmarkable. > > > > Can PageLink please be restored? > > > > Best regards, > > Emond Papegaaij > > > > - > > 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
Re: PageLink deprecated
what does the javadoc say? -igor On Thu, Jan 14, 2010 at 6:12 AM, Emond Papegaaij wrote: > Hi, > > We just found that PageLink has been deprecated in wicket 1.4. Can someone > explain why? I see no reason why PageLink should not be used. PageLink is the > base for SecurePageLink (in wicket-security), which uses getPageIdentity for > its security check. Using Link is not an option because it does not provide > the page identity, and using BookmarkablePageLink is not an option because in > many cases the target page is not bookmarkable. > > Can PageLink please be restored? > > Best regards, > Emond Papegaaij > > - > 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
PageLink deprecated
Hi, We just found that PageLink has been deprecated in wicket 1.4. Can someone explain why? I see no reason why PageLink should not be used. PageLink is the base for SecurePageLink (in wicket-security), which uses getPageIdentity for its security check. Using Link is not an option because it does not provide the page identity, and using BookmarkablePageLink is not an option because in many cases the target page is not bookmarkable. Can PageLink please be restored? Best regards, Emond Papegaaij - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: PageLink deprecated in 1.4
the two alternatives are mentioned in the javadoc. -igor On Tue, Jul 21, 2009 at 11:35 AM, David R Robison wrote: > I noticed that the PageLink class is deprecated in 1.4. What should it be > replaced with in my application code? David > > -- > > David R Robison > Open Roads Consulting, Inc. > 103 Watson Road, Chesapeake, VA 23320 > phone: (757) 546-3401 > e-mail: drrobi...@openroadsconsulting.com > web: http://openroadsconsulting.com > blog: http://therobe.blogspot.com > book: http://www.xulonpress.com/book_detail.php?id=2579 > > > > > > > - > 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
PageLink deprecated in 1.4
I noticed that the PageLink class is deprecated in 1.4. What should it be replaced with in my application code? David -- David R Robison Open Roads Consulting, Inc. 103 Watson Road, Chesapeake, VA 23320 phone: (757) 546-3401 e-mail: drrobi...@openroadsconsulting.com web: http://openroadsconsulting.com blog: http://therobe.blogspot.com book: http://www.xulonpress.com/book_detail.php?id=2579 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
