I've just noticed that some of the .js resources seem to be loading from
different addresses. I'm using 1.5.2 with the UrlRenderer patch to fix
the forwarding issue.
Depending on the page it appears like the same .js is requested at two
different URLs. Presumably the browser will perform a
this is a general problem with forwarding. instead of forwarding why
dont you just 302?
-igor
On Fri, Oct 21, 2011 at 11:33 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
I've just noticed that some of the .js resources seem to be loading from
different addresses. I'm using 1.5.2 with
The reason I don't do a 302 is I don't want the browser's address bar to
change + for SEO.
-Original Message-
From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
Sent: Saturday, 22 October 2011 5:52 PM
To: users@wicket.apache.org
Subject: Re: Forwarding in 1.5 not working like in 1.4
After creating a QuickStart and not being able to reproduce the problem I
discovered that my original app was linking with an earlier 1.5 snapshot. Once
I linked with the latest snapshot jars it magically worked - yeehah!
-Original Message-
From: Chris Colman
Will do.
Chris
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Sunday, 9 October 2011 6:07 PM
To: users@wicket.apache.org
Subject: Re: Forwarding in 1.5 not working like in 1.4
Can you create a quickstart ?
It looks like either javax.servlet.forward.url is
I have found that the method below appears to return the wrong result for
relativeUrl:
WebPageRender.java
protected void redirectTo(Url url, RequestCycle requestCycle)
{
WebResponse response =
(WebResponse)requestCycle.getResponse();
Could it be that Wicket sees the original URL as being / (i.e. home page) and
so performs a redirect to the home page? Possibly it should be looking at the
'forward' request URL which is not / but content/home/o/76429 and should be
handled directly without a redirect.
-Original
Looks like the redirect is due to the PRG strategy implementation so it's set
to REDIRECT_TO_BUFFER.
(From my, possibly naïve, understanding I thought you only needed PRG when a
form submission was involved but it looks like it's applied to every page
request).
I probably should keep using
We have a separate filter set up to catch parameter-less domain name
requests ( /* ) like:
www.myurl.com http://www.myurl.com/
and forward them to a bookmarkable home page like:
www.myurl.com/content/home/o/123
The extra o/123 is an organization discriminator name/value pair and is
read
