Re: Bug in WOContext.directActionURLForActionNamed() when using query dictionary
Re: Bug in WOContext.directActionURLForActionNamed() when using query dictionary
- Subject: Re: Bug in WOContext.directActionURLForActionNamed() when using query dictionary
- From: Mike Schrag <email@hidden>
- Date: Wed, 26 Apr 2006 20:32:34 -0400
David LeBer, Nov 15 2005 says a quick Mail search ... This teeters on
a religious debate I believe :) It comes down to how you are using
the result of that method. If you use it inside of an <a href =
".."> then it's SUPPOSED to be escaped (to be XHTML compliant).
However, apparently it fails if you try to use it with a WORedirect.
I have no idea what happens if you try to use that inside of
Javascript as a location = '..', and obviously if processing it in
some other way internally, it will probably throw your code for a
loop. So basically, if you were expecting it the old way, it's
broken, but if you thought it was broken before, it's fixed :)
ms
On Apr 26, 2006, at 8:05 PM, Chuck Hill wrote:
Not really sure I want to step into this... :-)
On Apr 26, 2006, at 3:49 PM, Nathan Hadfield wrote:
I seem to have encountered a bug in
WOContext.directActionURLForActionNamed(). When I pass it a query
dictionary containing more than one key, it returns a string in
which the query arguments are separted by '&' instead of just
an ampersand. As a result, if I pass a query dictionary containing
{ arg1 = x; arg2 = y }, it returns a URL looking like this:
/cgi-bin/WebObjects/AppName.woa/wa/MyActions/go?arg1=x&arg2=y
whereas the correct URL would be
/cgi-bin/WebObjects/AppName.woa/wa/MyActions/go?arg1=x&arg2=y
There was a long discussion on the list about this within the past
year. I don't recall the specifics other than something is wrong
and people had a hard time agreeing on what exactly it was.
IIRC, that URL is actually _correct_ for representing a URL in an
HTML file. What seems to be wrong is WO's form value processing
when it gets it back. Or maybe it was a browser failing to decode
it properly. I forget and I have too many headaches today to re-
open this one.
I have traced the problem down to a the private static method
com.webobjects.appserver._private.WOURLEncoder.encodeAsCGIFormValues(
NSDictionary dict )
which returns the encoded pairs joined by '&'.
I'm using WO 5.3 with Xcode 2.2.1. I'm pretty sure this was
working correctly in earlier versions.
Correctly is perhaps open to debate, but it was working differently
in earlier versions. I think this came about as part of a campaign
to modernize the html that WO produces.
My workaround for now is to either replace occurrences of '&'
in the result with just '&'--but this would cause problems if
there was a legitimate & in one of the query values. Another
option is include "amp;" as a prefix when retrieving form values
in the direct action.
You could also make your own subclass of WOContext, and fix this
method. You can call setContextClassName(java.lang.String) on
Application to get it to use your subclass.
I have submitted a bug report to Apple but I'm curious whether
anyone else has encountered this, or if anyone has a better
workaround?
Check the archives. I think there were some work arounds posted.
IIRC, it was Xavier who hit this problem.
FWIW
Chuck
--
Coming in late 2006 - an introduction to web applications using
WebObjects and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/
practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mdimension.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden