On 2009-11-18 at 17:29:00 -0600,
Jeff Ortel <jortel(a)redhat.com> wrote:
On 11/18/2009 02:44 PM, Dan Sommers wrote:
d = client.last_received()
s = str(d)
That was my first try, and it worked smashingly until one of my users
found some XML that contained an ampersand ("&") and a less than symbol
("<") within its text nodes. Somewhere in there, suds decoded the
entities twice, and str returned ill-formed XML (i.e., XML containing
actual ampersands and less than symbols in its text nodes instead of
"&"s and "<"s).
client.set_options(retxml=True)
d = client.service.foo()
s = str(d)
That's what my code looks like now, but without that last string
conversion (which apparently triggers that extra level of decoding?):
client.set_options( retxml = True )
s = client.service.foo( ... )
x = lxml.etree.XML( s )
...
... Also, won't you have the same problems with:
<snip>
> I'm having an awful time fixing up all of the namespaces and getting
> rid of the elements with xsi:nil="true" attributes.
</snip>
even if you had the raw string XML?
My tactical mistake was prematurely extracting an XML fragment from the
response and losing an essential xmlns attribute or three. Oops. ;-)
So now I take the *whole* response (i.e., the soapenv:Envelope element)
and run it through an XSL transform that pulls out the fragment I need,
re-wraps that fragment in a new element, and removes elements with
xsi:nil="true" attributes. The namespace issue went away once I fixed
my approach.
The exact XML (stream) returned by the server is consumed by the sax
parser (inline) and isn't really available. To capture it, I would
have to read the entire document into memory then sax parse the
string.
What you're doing is definitely the right approach (not that you need my
approval!). My use of the word "original" referred to the character
entity issue I described above.
Thank you, for both suds and your reply.
Dan