depricated api
Locked
 
|
Hi there,
today I tried to specifiy the target of an anchor and ran into the #depricatedApi again. I like the idea of how depricatedApi works in terms of you see which methods you call that you shouldn't call as they're depricated, but there's one small piece of information missing: what should I use instead? Wouldn't it make more sense to add an argument to this message with some sort of hint telling the developer what to do instead? The only alternative to me seems to use the same code that's inside the #target: method in my own application but without the depricatedApi call. That's absolutely not what I'd like to do though, maybe someone else has a better idea. Kind Regards Karsten -- Karsten Kusche - Dipl.Inf. - [hidden email] Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Hi,
#target: (and the attribute target="") was removed from the (X)HTML spec and thus removed from Seaside. The alternative is to give the link a relation of external (i.e. html anchor relation: 'external'; url: 'http://www.foo.com'; with: 'foo') and run the script externalLinks (which is included with Seaside) like so: html script: 'externalLinks()' Regards, John Karsten wrote: > Hi there, > > today I tried to specifiy the target of an anchor and ran into the > #depricatedApi again. I like the idea of how depricatedApi works in > terms of you see which methods you call that you shouldn't call as > they're depricated, but there's one small piece of information missing: > what should I use instead? Wouldn't it make more sense to add an > argument to this message with some sort of hint telling the developer > what to do instead? > > The only alternative to me seems to use the same code that's inside the > #target: method in my own application but without the depricatedApi > call. That's absolutely not what I'd like to do though, maybe someone > else has a better idea. > > Kind Regards > Karsten > -- John Thornborrow http://www.pinesoft.co.uk ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Thanks for the info!
feels a bit strange though to use relations and then execute a javascript that puts the target="_blank" back into the anchor. Kind Regards Karsten John Thornborrow wrote: > Hi, > > #target: (and the attribute target="") was removed from the (X)HTML > spec and thus removed from Seaside. > > The alternative is to give the link a relation of external (i.e. html > anchor relation: 'external'; url: 'http://www.foo.com'; with: 'foo') > > and run the script externalLinks (which is included with Seaside) like > so: > > html script: 'externalLinks()' > > Regards, > John > > Karsten wrote: >> Hi there, >> >> today I tried to specifiy the target of an anchor and ran into the >> #depricatedApi again. I like the idea of how depricatedApi works in >> terms of you see which methods you call that you shouldn't call as >> they're depricated, but there's one small piece of information >> missing: what should I use instead? Wouldn't it make more sense to >> add an argument to this message with some sort of hint telling the >> developer what to do instead? >> >> The only alternative to me seems to use the same code that's inside >> the #target: method in my own application but without the >> depricatedApi call. That's absolutely not what I'd like to do though, >> maybe someone else has a better idea. >> >> Kind Regards >> Karsten >> > -- Karsten Kusche - Dipl.Inf. - [hidden email] Georg Heeg eK - Köthen Handelsregister: Amtsgericht Dortmund A 12812 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |