Okay, did some more poking and I need to update my observation. I thought it was the resetting of ignoreWhitespace that was causing things to revert. Actually it was the resetting of the prettyPrinting setting to it's original value (of true) at line 175. So ultimately my current workaround is to make sure pretty printing stays set to false. But there has to be a way to have trailing spaces in string values. I am assuming that the string values are properly escaped as a xml string value, since we are encoding everything.
Chris On Wed, Feb 19, 2014 at 11:05 AM, Chris Martin <windo...@gmail.com> wrote: > So, I've run into this problem back in Flex 3, and did some "interesting" > things to get around it. I'm now wondering if either a.) it was a true > problem in the SDK and I needed to keep my workaround or b.) I just never > truly understood how to get this to work properly without "hacking it" > > Problem originally was that I needed to keep trailing spaces in string > values going to and from the SOAP API. Seems the SOAP proxy classes being > generated by Flash Builder 4 and up leverage the WebService class and > Operations to communicate with the SOAP interface. So my first question > would be how do I ensure that trailing spaces in the string values is kept? > > Now briefly back to my "hax" to solve the problem before. Back in the day > I felt that I traced the problem to the SOAPEncoder with the > "encodeRequest" function. The ignoreWhitespace can be overridden (at line > 168 in the 4.11 sdk) but is then immediately reset after encoding to it's > original value. While tracing the execution I noted that the encoding > completed properly and kept the trailing spaces after passing line 170 > (envelopeXML = encodeEnvelope(args, headers);); however, the trailing > spaces would disappear when I actively inspect the envelopeXML variable > after passing line 174 (XML.ignoreWhitespace = oldIgnoreWhitespace;) where > the old ignoreWhitespace value is restored. > > So that's it. Not sure if I'm just doing it wrong, or if it's a bug in > the SDK. > > Thanks, > > Chris >
