From: Tony Collen [mailto:[EMAIL PROTECTED]
<snip/>
Jeff,
Could you try the following test and tell me if you get search results?
Worked great! Thanks!
Yes, but I've re-opened the bug, because it really isn't re-encoding the request parameters correctly. The WSProxy, along with the newer HttpProxy, get request parameters from two different sources.
The first is from the "src" attribute, like so:
<map:generate type="wsproxy" src="http://foo.bar/endpoint?parm1=val1&parm2=val2"/>
The second is from any parameters that were passed to the matching pipeline. All of the parameters are gathered together and then shipped off to the remote server in one go. Check out the fetch() method of the WebServiceProxyGenerator.
The problem is that the parameters in the first example, which are included in the src attribute, are not being correctly encoded. I have yet to fix this, but I'll work on it. The WSProxy will probably eventually go away in favor of the HttpProxyGenerator, soon anyway.
<snip/>
I think what is happening in your example is that when you use {request-param:actor}, that is being decoded by the RequestParameterInputModule, and is therefore being sent unencoded to Amazon (I could be wrong on this). The WSProxy automatically sends all request parameters which were sent from the original form, so if you have a field called "ActorSearch" in your field, the WSProxy will also send ActorSearch=foo to the remote service.
Interesting. What happens if I don't want to pass my parameters along?
The other problem that I found is when you want to "rename" the request parameters which are then passed to the wsproxy. (When you don't want to pass all the parameters along or you wish to rename them).
In this case, you would have something like this:
<map:match pattern="formSubmit">
<map:generate type="file" src="http://foo.com/service?parm1=val1&parm2={request-param:fooParam}"/>
<map:serialize type="xml"/>
</map:match>
I noticed there was a "RawRequestParameterModule" which provides the "undecoded" request parameter. Your specific problem I believe was that the use of {request-param:actor} was causing the parameter to be decoded with the space (to "johnny depp"), and then you were directly sending that string with the space to the remote service, which is incorrect. The correct use would be {raw-request-param:actor}.
Note that you don't actually need the WSProxy in your case, since it's all XML over HTTP (the FileGenerator can handle that just fine), and you don't neccesarily want to pass all of your form variables directly through to Amazon.
I wish I understood the Cocoon code better. I'd like to take a look at it--especially with your help. I see you've posted a couple of other things today, so I'm not sure if you've moved on from this proposed solution. In any case I'm all ears...
Yep, it's taken me a while to get back into digging through everything again. I suppose for now, use the FileGenerator, along with the raw-request-param InputModule. I ran into problems getting the WSProxy to encode stuff, even stuff coming out of the raw-request-module. I suspect this bug also occurs inside the HttpProxy, so I will have a look at both. Part of my problems are from my inexperience with commons-httpclient, which both the WSProxy and the HttpProxy use.
Jeff
Tony
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
