There's a MiltonKeynes.pm (http://miltonkeynes.pm.org/) technical meeting this evening, organised by Tom Hukins.
Now I just need to finish my slides...
Which are nothing to do with what I've been working on recently. $dayjob has me wrapping a third party's SOAP API. We need to do this because although they have a very pretty web site for carrying out various back-end operations, it doesn't meet our audit requirements. It would also mean retraining our ops people to stop using our systems and start using theirs.
This is my first foray in to SOAP, and it's going reasonably well. But what hadn't occured to me is how much of the verboseness of XML would have to spill over in to my code.
I'm trying to make sure that the wrapper I'm writing is going to be easy to use for someone who's experienced with Perl, as well as looking close to the underlying API for someone who's familiar with that -- I'm not entirely sure why, as I'm not sure this code is ever going to see the light of day outside of $dayjob, but I get a definite sense of satisfaction out of doing these things properly.
Anyway, I digress.
So the responses back from the API all come back as XML, naturally, and SOAP::Lite does a reasonably good job of turning these in to useful Perl datastructures. I then convert these (hashes, normally) in to objects, and return the objects.
This forces the caller to use get_ and set_ methods to retrieve the data, which is less error prone than having them specify the hash keys directly.
And this is where the XML verbosity spills over in to the client interface. Handed XML like this:
the client API looks like this:
(not sure why u.p is inserting spaces in to some of those).
Still, I suppose it makes the code more readable in the long run.