> That & does not work is clear, but I don't see any reason why & > shall not work.
This seems to be a limitation of the Domino server that I am attempting to communicate with. No only does it not respond to anything by an actual "&" character, but the parameters are expected in a specific order. It's not so much fun working with closed systems like that. Alas, it's my job to make this work, or find another integration solution for my company... =(
> The difference of the wsproxy is that you can send the request with the > POST method.
The other being that the HTML Generator can handle non well formed xml, and fix it. I don't trust these systems to spit out well formed xml all the time, so that's why I'm using that one. The Proxy Generator still won't help me get around my ampersand problem.
Is there any way for me to use an actual & character in any block to help me get this
external data? Besides making changes to, or rewriting one of those generators? I think
something like this would be ideal:
<map:match pattern="hi.html">
<map:generate src="http://DOMINOSERVER/mail/username.nsf";>
<map:parameter name="Login" value=""/>
<map:parameter name="Username" value="me"/>
<map:parameter name="Password" value="Password"/>
<map:parameter name="RedirectTo"
value="/mail/username.nsf/($Inbox)?ReadViewEntries"/>
</map:generate>
<map:transform src="style/xsl/process.xsl"/>
<map:serialize type="html"/>
</map:match>Or something to that effect...
-Dana Cordes
Joerg Heinicke wrote:
On 05.02.2004 01:47, Dana Cordes wrote:
<map:generate src="http://DOMINOSERVER/mail/username.nsf?Login&Username=me&Password=pass&RedirectTo=/mail/username.nsf/($Inbox)?ReadViewEntries" type="xml"/>
But, this of course doesn't work since the "&" character that I use in the url src is a no no in an XML document. If I replace the "&" with "&" or even "&" or "&" the url does not resolve correctly, and I cannot get my content.
That & does not work is clear, but I don't see any reason why & shall not work.
Is there another, better way to do this? I'd use the WebServiceProxyGenerator but I'd find the same problem there.
The difference of the wsproxy is that you can send the request with the POST method.
I've seen this come up in the mail archives regarding POST requests, but I haven't found a real clear answer yet.
I only remember problems when you want to reuse request parameters sent to Cocoon on the request to the other server. There was a problem with encoded and decoded parameters, but not with an URL built like yours above.
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- "A lot of nerds who graduated from AD&D and couldn't get their fix probably moved on to Scientology. It provides a lot of the same attractions. Geekiness, advancement levels, psionics, continued financial investment." --http://www.rotten.com/library/culture/dungeons-dragons/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
