You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by n8han <na...@technically.us> on 2007/05/12 16:30:05 UTC
relative URL refactor (maybe?) and request target regressions
Previously I was able to mount bookmarkable paths including a slash in 1.3.0
snapshot, but now ajax request targets on those pages are failing. There is
no exception logged; the browser redirects to
resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js.
A separate problem is that request targets (ajax and regular) are no longer
being processed under mounted bookmarkable URLs as they were up until now on
1.3.0. A mount like /code have targets like /code?wicket:... , but not they
are /?wicket: as in Wicket 1.2. Is this intentional?
Nathan
--
View this message in context: http://www.nabble.com/relative-URL-refactor-%28maybe-%29-and-request-target-regressions-tf3731957.html#a10446369
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: relative URL refactor (maybe?) and request target regressions
Posted by n8han <na...@technically.us>.
Al Maw wrote:
>
> I've quite probably just fixed that, literally as you posted. Update and
> try it now.
>
> Apologies for the slight URL instabilities over this weekend. I've been
> trying to get our URL handling in shape for the forthcoming 1.3 release,
> and just after beta1 and over a weekend seemed to be a good time to do
> that. Hopefully everything is now in good shape.
>
Yes, that did it thank you. No worries--we all know the risks of depending
on snapshots.
Nathan
--
View this message in context: http://www.nabble.com/relative-URL-refactor-%28maybe-%29-and-request-target-regressions-tf3731957.html#a10457803
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: relative URL refactor (maybe?) and request target regressions
Posted by Al Maw <wi...@almaw.com>.
n8han wrote:
>
> Al Maw wrote:
>> Turns out this is actually required. I've patched in an extra param in
>> RequestParameters for the URL depth of the original page, and updated
>> the interface listener request encoding stuff to cope. Hopefully we
>> should now be able to trivially support hybrid URLs in future and
>> everything should now work as intended. ;-)
>>
>
> I'm not sure if we're talking about exactly the same thing there; I'm still
> getting ajax requests to /?wicket... from a mounted page, with the current
> trunk. But I found some Apache proxy magic to make that ok with my setup:
>
> RewriteCond %{QUERY_STRING} ^wicket
> RewriteRule ^/$ http://localhost:8280/ [P]
>
> (I have an application that thinks it has a root context, but I only proxy
> requests to it from certain paths.)
>
> So that's fine, but modal window is not happy on those sub-pages. It opens
> correctly now, but buttons and links off of it fail with a redirect to a
> blank page as was happening before with ajax links from the page itself.
I've quite probably just fixed that, literally as you posted. Update and
try it now.
Apologies for the slight URL instabilities over this weekend. I've been
trying to get our URL handling in shape for the forthcoming 1.3 release,
and just after beta1 and over a weekend seemed to be a good time to do
that. Hopefully everything is now in good shape.
Regards,
Al
Re: relative URL refactor (maybe?) and request target regressions
Posted by n8han <na...@technically.us>.
Al Maw wrote:
>
> Turns out this is actually required. I've patched in an extra param in
> RequestParameters for the URL depth of the original page, and updated
> the interface listener request encoding stuff to cope. Hopefully we
> should now be able to trivially support hybrid URLs in future and
> everything should now work as intended. ;-)
>
I'm not sure if we're talking about exactly the same thing there; I'm still
getting ajax requests to /?wicket... from a mounted page, with the current
trunk. But I found some Apache proxy magic to make that ok with my setup:
RewriteCond %{QUERY_STRING} ^wicket
RewriteRule ^/$ http://localhost:8280/ [P]
(I have an application that thinks it has a root context, but I only proxy
requests to it from certain paths.)
So that's fine, but modal window is not happy on those sub-pages. It opens
correctly now, but buttons and links off of it fail with a redirect to a
blank page as was happening before with ajax links from the page itself.
--
View this message in context: http://www.nabble.com/relative-URL-refactor-%28maybe-%29-and-request-target-regressions-tf3731957.html#a10457398
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: relative URL refactor (maybe?) and request target regressions
Posted by Al Maw <wi...@almaw.com>.
Al Maw wrote:
> n8han wrote:
>> Previously I was able to mount bookmarkable paths including a slash in 1.3.0
>> snapshot, but now ajax request targets on those pages are failing. There is
>> no exception logged; the browser redirects to
>> resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js.
>
> As mentioned in the other e-mail, this should be fixed now. It was
> caused by a small oversight in some refactoring, for which I apologise.
>
>> A separate problem is that request targets (ajax and regular) are no longer
>> being processed under mounted bookmarkable URLs as they were up until now on
>> 1.3.0. A mount like /code have targets like /code?wicket:... , but not they
>> are /?wicket: as in Wicket 1.2. Is this intentional?
>
> Yes, this is intentional, and it shouldn't be causing any problems
> (although it may get in the way of hybrid URLs, but we can fix that
> post-1.3).
>
> The reason for this is primarily due to how AJAX HeaderContributions
> work. CSS/JS/whatever needs to be relative to the URL for the page that
> is being viewed. When an AJAX request comes in, if the URL for the AJAX
> request at the same "../ depth" as the page view itself, then we just
> construct resource links relative to that, and it all works. Otherwise,
> we need to maintain state for the depth of the original page render.
> This is possible, but less easy, and I don't want to mess with this
> prior to the 1.3 release.
Turns out this is actually required. I've patched in an extra param in
RequestParameters for the URL depth of the original page, and updated
the interface listener request encoding stuff to cope. Hopefully we
should now be able to trivially support hybrid URLs in future and
everything should now work as intended. ;-)
Let me know if you see any oddness.
Al
Re: relative URL refactor (maybe?) and request target regressions
Posted by Al Maw <wi...@almaw.com>.
n8han wrote:
> Previously I was able to mount bookmarkable paths including a slash in 1.3.0
> snapshot, but now ajax request targets on those pages are failing. There is
> no exception logged; the browser redirects to
> resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js.
As mentioned in the other e-mail, this should be fixed now. It was
caused by a small oversight in some refactoring, for which I apologise.
> A separate problem is that request targets (ajax and regular) are no longer
> being processed under mounted bookmarkable URLs as they were up until now on
> 1.3.0. A mount like /code have targets like /code?wicket:... , but not they
> are /?wicket: as in Wicket 1.2. Is this intentional?
Yes, this is intentional, and it shouldn't be causing any problems
(although it may get in the way of hybrid URLs, but we can fix that
post-1.3).
The reason for this is primarily due to how AJAX HeaderContributions
work. CSS/JS/whatever needs to be relative to the URL for the page that
is being viewed. When an AJAX request comes in, if the URL for the AJAX
request at the same "../ depth" as the page view itself, then we just
construct resource links relative to that, and it all works. Otherwise,
we need to maintain state for the depth of the original page render.
This is possible, but less easy, and I don't want to mess with this
prior to the 1.3 release.
Al
Re: relative URL refactor (maybe?) and request target regressions
Posted by Al Maw <wi...@almaw.com>.
Jonathan Locke wrote:
> i'm getting this exact problem too. is there a JIRA issue for this yet?
Sorry. I'm fixing this right now. ;-)
Al
Re: relative URL refactor (maybe?) and request target regressions
Posted by Al Maw <wi...@almaw.com>.
Hi folks,
Can you do a SVN up on trunk and see if this is now fixed for you?
Al
Jonathan Locke wrote:
>
> i'm getting this exact problem too. is there a JIRA issue for this yet?
>
>
> n8han wrote:
>> Previously I was able to mount bookmarkable paths including a slash in
>> 1.3.0 snapshot, but now ajax request targets on those pages are failing.
>> There is no exception logged; the browser redirects to
>> resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js.
>>
>> A separate problem is that request targets (ajax and regular) are no
>> longer being processed under mounted bookmarkable URLs as they were up
>> until now on 1.3.0. A mount like /code have targets like /code?wicket:...
>> , but not they are /?wicket: as in Wicket 1.2. Is this intentional?
>>
>> Nathan
>>
>
Re: relative URL refactor (maybe?) and request target regressions
Posted by Jonathan Locke <jo...@gmail.com>.
i'm getting this exact problem too. is there a JIRA issue for this yet?
n8han wrote:
>
> Previously I was able to mount bookmarkable paths including a slash in
> 1.3.0 snapshot, but now ajax request targets on those pages are failing.
> There is no exception logged; the browser redirects to
> resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js.
>
> A separate problem is that request targets (ajax and regular) are no
> longer being processed under mounted bookmarkable URLs as they were up
> until now on 1.3.0. A mount like /code have targets like /code?wicket:...
> , but not they are /?wicket: as in Wicket 1.2. Is this intentional?
>
> Nathan
>
--
View this message in context: http://www.nabble.com/relative-URL-refactor-%28maybe-%29-and-request-target-regressions-tf3731957.html#a10452464
Sent from the Wicket - Dev mailing list archive at Nabble.com.