This was also no doubt caused by a naughty build script here which pulled in old versions of the wicket jars!
>-----Original Message----- >From: Chris Colman [mailto:[email protected]] >Sent: Wednesday, 18 January 2012 6:32 AM >To: [email protected] >Subject: RE: JavaScript links - correct URL generated? > >Yes, on the 1.5-SNAPSHOT - pulling updates every few hours =] > >In our latest version of the app the problem is indeed fixed - what I >think I'm seeing now is the result of google requesting the bad links it >cached when the problem was present. If I make requests to those links >give a 301 redirect to the home page or whatever Google should uncache >the bad links after a while. > >Thanks, >Chris > >>-----Original Message----- >>From: Martin Grigorov [mailto:[email protected]] >>Sent: Wednesday, 18 January 2012 1:42 AM >>To: [email protected] >>Subject: Re: JavaScript links - correct URL generated? >> >>Are you still on 1.5-SNAPSHOT ? >>This have been fixed with WICKET-4290 few days ago >> >>On Tue, Jan 17, 2012 at 3:35 PM, Chris Colman >><[email protected]> wrote: >>> Wicket rendered this page: >>> >>> http://www.myurl.com.au/content/newArticle/o/76429/ar/486 >>> >>> It is mounted at /content/newArticle using a >>> UrlPathPageParametersEncoder >>> >>> And /o/76429/ar/486 are named paramters as per 1.4 style >>> >>> Wicket generates the following <a> tag when it rendered the page: >>> >>> <a style="float: right;" wicket:id="loginBtn" id="loginBtn21" href="# >>> ><view-source:http://web.barcodedirect.com.au/content/newArticle/o/76429 / >>> ar/486> " onclick="var >>> >wcall=wicketAjaxGet('../../../../newArticle?3-1.IBehaviorListener. 0 >>> -body-systemPanel-loginSubpanel-loginBtn',function() { >>> }.bind(this),function() { }.bind(this), function() {return >>> Wicket.$('loginBtn21') != null;}.bind(this));return >>> !wcall;"><img src="/images/arrowRight16.png >>> <view-source:http://web.barcodedirect.com.au/images/arrowRight16.png> >" >>> alt="Sign in" title="Sign in"/></a> >>> >>> >>> Now this works fine in a browser and does what it should when the >user >>> clicks on the login button but the problem has arisen in 1.5 when the >>> Google robot crawls the site. I don't know why it tries to request a >URL >>> with a href="#" and JavaScript but it does and the results aren't >good. >>> >>> Google makes a request to: >>> >>> >http://www.myurl.com.au/content/newArticle?3-1.IBehaviorListener.0-body - >>> systemPanel-loginSubpanel-loginBtn' >>> >>> Which fails because the URL does not contain the required named >>> parameters above: /o/76429/ar/486 >>> >>> It's like AJAX/Javascript assumes that named parameters stored in the >>> path are not important when it comes to generating a new URL with >it's >>> own named parameters (i.e. the IBehaviorListener). >> >> >> >>-- >>Martin Grigorov >>jWeekend >>Training, Consulting, Development >>http://jWeekend.com >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [email protected] >>For additional commands, e-mail: [email protected] > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
