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(&#039;../../../../newArticle?3-1.IBehaviorListener.0
>> -body-systemPanel-loginSubpanel-loginBtn&#039;,function() {
>> }.bind(this),function() { }.bind(this), function() {return
>> Wicket.$(&#039;loginBtn21&#039;) != 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&#039
>>
>> 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]

Reply via email to