in reply to Re: Syntax used by SOAP::Lite
in thread Syntax used by SOAP::Lite

Yeah that all makes sense now that I've played around with it a bit more, as I realised I can make a call to things that clearly don't exist, and no perl error is generated.. it just quietly populates the soap fault data.

Changing topics again, the problem I have now is more related to XML parsing. If I look at the actual packets coming back from the server, I can see that it has two occurances of '<lines>' in the data, but after parsing, only the first has made it through.

I remember from when I was trying to decode the stuff myself using XML::Parser and XML::Twig that there were various options in there that could be used to change how things like that are decoded, but I haven't had a chance yet to see if the XML parser options are visible via the SOAP::Lite object.

And once again, thanks to everyone for their help here.

  • Comment on SOAP::Lite and XML::Parser decoding issues

Replies are listed 'Best First'.
Re: SOAP::Lite and XML::Parser decoding issues
by jhourcle (Prior) on Jun 04, 2005 at 22:24 UTC

    SOAP -- and I'm being nice here -- is a pain in the ass.

    It's even worse than dealing with HTML interoperability, because it's cumbersome to set up a range of tests for each toolkit, as it can require setting up a seperate client built from each toolkit.

    There are many, many things that can go wrong when trying to parse the results, but here are a few to start you off:

    • the SOAP::SOM object returned from a method call has a lot more detail than the value returned from $som->result(). The result() method only returns the _first_ value returned, if it was a list.
    • Look into the paramsout() and paramsall() methods to SOAP::SOM
    • You can access values via XPath using the valueof() method to SOAP::SOM.

    Look over the SOAP::Lite documentation ... and as you try more with it, look over it again. It hardly made any sense to me the first time through, over a year ago, but as I use it more, it starts making more and more sense.

    As you start working with it more, you'll find that it makes a whole lot of assumptions, that can make easy cases trivial to implement, but causes a whole lot more work when the assumptions fail ... like if '20040101' is a string, not an integer... or if you're trying to emulate a document/literal webservice as opposed to RPC/encoded.

      Thanks. I've already looked at paramsout() and paramsall() and they didn't seem to give me the other instances of <lines>, but I'll have a play with valueof() and see if that gets me anywhere.

      Yep.. just tried it quickly, and valueof('//line') seems to do the trick. I'm not up to speed with xpath syntax yet though, so I'll have to do some reading.