02
Jun
05

In the old days, soap was what went into your mouth when bad words came out…

instead, SOAP (or at least SOAP::Lite, which is a Perl implementation of it) seems to have gone in and caused bad words to come out.

This all started because I wanted a programmatic web interface for BU’s database, rather than either knocking up PHP pages with mySQL commands, or giving people other than myself mySQL access (or exploring the horrors of SQL stored procedures!!). Having encountered both SOAP and XML-RPC during my travels at TransACT (they use SOAP for some things internally, but XML-RPC for the ISP policy-control interface. I think they’ve got distinct groups of programmers with similar ideas, but no way of talking to each other… This would explain a lot about the projects I end up doing — or more to the point not doing — for TransACT. ^_^) I decided I’d go with some kind of RPC interface where I could knock the back-end up in Perl, and the front end could be PHP or whatever the reseller wanted. I have some vision of a customer control applet regular customers could use at home, but I think that’s asking a little too much.

Anyway, after due and careful consideration of my database structure, it seemed obvious that an object encapsulation would be a good idea. So SOAP won out over XML-RPC. As far as interface goes, SOAP::Lite implements XML-RPC too. So this wasn’t a consideration. Sure enough, I’m hacking away, rereading my recent Perl-based object-oriented adventures in module creation (the aforementioned policy thingy) and rather quickly manage to produce a getCustomer() function in the BU module which returns a BU::Customer object. I happily assume that since SOAP is supposed to pass objects around, I’ll be able to call the functions of this new and wonderful object, and have the code on the server-side execute.

This of course does not happen. (Why “of course”? If it did happen, this post would be titled ‘The wonder and glory of SOAP’ or something. And have been done about 36 hours earlier. >_<)

Instead, I get an object back with no routines. “Ah!” I hear you cry. “A perl method call is simply a call to the function in the module for which the class was blessed, with the object itself as the first parameter!” (Others amongst you may cry “That’s not really object-oriented, it’s object-like!”. It’s a fair point, but somewhat irrelevant. I use perl because I think programmers don’t use enough punctuation, not because of any particular programming language construction leanings. I own the Eiffel book, but never read it. ^_^)

Now that that crying has died down, I did indeed try that. However, the SOAP::Lite instance I was using had ‘/BU’ at the end of its URI (which is now called a namespace, apparently) so it tried to call the non-existant function in the BU module. So I instantiated a new SOAP::Lite instance, looking at ‘/BU/Customer’. That didn’t work either, at which I point I realised this was excessive mucking about for what I wanted, and spent a day or two writing a procedural version instead.

I ended up with something like the following:


package BU;
# "field => value" is repeatable infinitely. Unknown fields will be silently
# dropped, if there's not enough to go on, we will abort before any database
# changes are made.
# Only admins may specify a different customer ID to their own
sub GetCustomer(optional CustomerID);
# Only admins may specify a different customer ID to their own
sub EditCustomer(optional CustomerID, field => value, field => value);
# Only admins may use this at all
sub NewCustomer(field => value, field => value);
# Only admins may specify a different customer ID to their own
sub GetAccountList(optional CustomerID);
# Only admins may specificy an account not owned by them.
sub GetAccount(AccountID);
# Only admins may specificy an account not owned by them.
sub EditCustomer(AccountID, field => value, field => value);
# Only admins may specify a different customer ID to their own
sub NewAccount(field => value, field => value);
# Only admins may specificy an account not owned by them.
sub GetLoginList(AccountID);
# Only admins may specificy a login not owned by them.
sub GetLogin(LoginID);
# Only admins may specificy a login not owned by them.
sub EditLogin(LoginID, field => value, field => value);
# Only admins may specificy an account not owned by them.
sub NewLogin(field => value, field => value);

on the plus side, it’s done.

Now I have to go learn perldoc, but that’s probably not as hard as I suspect it is. ^_^

Edit: I’m not sure what’s wrong with my linebreaks, but they’re being ignored. Also, the <code> element produces its own block, so I can’t use it inline. I may remove them from the paragraphs in future, in case that fixes the line breaks.

Edit 2: Looks like a wordpress upgrade or my screwing around with modules means I no longer get automatic <p> tags in my text. So I have to add them by hand. And <code> puts <pre/> around its contents, so I have replaced it with <em> inline. >_< Also, the layout here gets boned by the <pre/> and so my right-hand menu gets pushed down to the bottom.

Edit 3: Geshi’s breaking blank lines as </p><p> which would be OK if the code was in a <p/> rather than a <div/>…


1 Response to “In the old days, soap was what went into your mouth when bad words came out…”



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: