I'm glad you wrote this up because I thought I was going crazy.
In my case, I'm using the FlexBuilder-generated web services client code in
AIR. The SOAPEncoder and XMLEncoder classes actually end up double-escaping any
XML characters in strings that are being passed up to my web service so a
simple "<" character becomes "&lt;", which is decoded on the other end as
"<" instead of as "<".
I can see where it's happening. XMLEncoder.as, line 1784, looks like this:
currentChild.appendChild(xmlSpecialCharsFilter(Object(value)));
The "xmlSpecialCharsFilter" is doing the escaping, then appendChild (as your
note points out) escapes the string again.
Of course, since the problem is too much escaping, pre-escaping the string
won't help.
The only way around it in XMLEncoder is to replace the xmllSpecialCharsFilter.
But in my case, I'm using the FlexBuilder-generated web services code (from
Data -> Import Web Services). So for now I'm editing that code. Of course that
means I have to re-edit the code each time my service changes and I regenerate
it. What a pain.
Here's what I did, in Base<servicename>.call:
var enc:SOAPEncoder = new SOAPEncoder();
enc.xmlSpecialCharsFilter = function(value:Object):String {return
value.toString()}
var soap:Object = new Object;
That works, but only in AIR (I assume, not really trying it in Flex).
So there's a hacky workaround. But really this should be fixed. At the very
least, the FlexBuilder-generated code should be set up to work in either
environment. As it is, "Import Web Services" will err for an AIR app where
there is a "<" or "&" in any text property passed to the web service.
Is there a bug for this?
