On Mon, Jan 2, 2012 at 8:18 AM, Taneli Korri <tko...@gmail.com> wrote:
> On Sat, Dec 31, 2011 at 4:31 PM, Martin Grigorov <mgrigo...@apache.org> wrote:
>> On Sat, Dec 31, 2011 at 2:29 PM, Taneli Korri <tko...@gmail.com> wrote:
>>> On Sat, Dec 31, 2011 at 9:09 AM, Martin Grigorov <mgrigo...@apache.org> 
>>> wrote:
>>>> On Fri, Dec 30, 2011 at 11:43 PM, martin.dilger
>>>> <martin.dil...@googlemail.com> wrote:
>>>>> hi,
>>>>> you could try to change your render strategy to redirect to render, that
>>>>> would dismiss the page
>>>>> parameters version.
>>>>
>>>> This is not correct.
>>>> The page id is encoded in the url only for stateful pages. Make your
>>>> page stateless and it wont be there.
>>>>
>>>
>>> OK, thanks for the info.
>>>
>>> If I remember correctly, in Wicket 1.4 stateful pages had also clean
>>> urls if the page was mounted to a certain path, i.e. the page version
>>> number was stored somewhere behind the scenes. I'm guessing this isn't
>>> possible anymore in Wicket 1.5?
>>
>> Everything is possible.
>> The new IRequestMapper are easily extensible and you can even use your own 
>> one.
>> By default this special parameter is set so when the user presses F5
>> (Refresh) the page Wicket will deliver the same version of the page.
>> Otherwise a new instance will be created without the knowledge of the
>> exact version.
>>
>> Why do you want to hide this parameter ?
>>
>
> Plain and simple, I like clean urls that can be bookmarked.

The urls with the page id can be bookmarked. If the requested version
of the page is not available then a new version is created and
delivered.

>
> Also some of the search engine bots save the crawled urls (with
> parameters) and try to access them at a later time. I found this out
> when I updated one of my sites and now I'm seeing a lot of 500
> Internal error responses in my web server logs.

Can you paste the stacktrace of an exception caused by such request ?

>
> Regards,
> Taneli Korri
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to