Recently I found myself doing a large amount of tedious coding. This came out from the specification analysis I had been doing. Large amounts of data elements mapped to IDs, and different column names in different databases. Somehow I had to make the code work. Instead of just jumping in and writing all of the code I decided to think about a smart way to do it first (which is always a good idea). I must say I love VIM. Many others can not stand it, it's so old school. There are all these nice graphical tools available. Bah I say. I had a column of 60 odd variable names, which also needed to be used as associative array indexes, and in many other spots to reference form objects and on and on. I just created a text file listing the names which made it simple to wholesale insert them in VIM
:r <filename>
But who do you make use of the columns now? I also love VIM because of recordable macros. Record the steps you go through, and you can access those steps easily by typing
@ <macroname>
So I prefixed, and suffixed the list of names with the same calls. Then to run through a process like ... go to the first dollar sign in the line ($), take the entire text between the dollar sign and the comma, move to the empty quotes (''), paste the text you copied in between them, and make it all lower case. the move to the next line, and the next dollar sign. I simply hit "q" to start recording, and gave it a name. Did my process and ran that macro until my code was complete. lets see dream weaver pull that one off. ;-)
I found myself in the office doing some remote work for a client. Let's jsut say I was bailing them out again. they have had some other people looking after things, and I must say it was not pretty. I found all sorts of things that were simply broken. I couldn't even do what they asked until I first fixed the broken features. I consider myself a nice guy, so I was going to do a couple of things gratis. When I realized I would have to fix things back to my original code, there was no way I could let that go for free. That's a bad move to make. It all worked out, and I ended up making all of the changes live on the production server. The second group of programmers decided to remove the original product from version control, so I had no other choice when I was no where near my usual set up. It's Sunday evening, so I wasn't worried at all.
It was also my birthday on Friday. The big 27. People bought lots of ice cream cake. Twice in one day. Karen Kneier also got me a fancy cigarette package. Way cool! We went out Friday to the Knockanback, then to the Lucy bar, and Hush. There were lots of interesting people out in
Maybe next year.
The basic run down is like this. We need to build a web service. We have the brains of things in VFP applications. A new system in PHP that needs to make use of this web service. One would think it would be easy to do this. I would say it's easy now that I have it figured out. I spent most of three days making all of the parts work properly to allow the PHP site to execute 3 lines of code.
That may seem like a whole lot of work to do that. But it's pretty slick in the end. It's actually cool when you think about what really happens in there. A VFP application is built as a multi-threaded dll. You then publish your com object as a webservice to an IIS server. You even get to select what methods are made public by this web service. All of the needed files are generated for you, and VFP even offers a testing application for web services to make sure it works. In this simple case I create a SOAP client object in PHP based on the WSDL file published by my web service. This creates an new class and provides methods that match the public methods of the web service. I can simply call these methods from my new object, and pass any parameters as needed.
$client = new SoapClient($wsdl_url);
$which = "BYE";
$rv = $client->hello($which);
The entire SOAP protocol is hidden underneath the scenes. I do not have to worry about the XML creation. The wsdl is taken care of by VFP. I do not have to worry about the SOAP envelopes. Connections are handled. I simply create and call. Getting this to work was no small feat however. When you think about it there are so many different parts at work here. SOAP is a very complex idea. Where do you start when something goes wrong?
Is the problem in the PHP code? Is the problem in the PHP library code used, or the PEAR module used? Is the problem on the client web server? Is the problem on the receiving IIS server? Is the problem in the connection bewteen the two? Is there a problem with access restrictions? Is the problem in the VFP code? Is the problem with windows not releasing the dll once it has been loaded and recompiled? Is the problem with the generated web service files? As you can see there are lots of areas to look into. I looked into all of these and more.
I have very little experience with VFP. However if you have written code once it's pretty much the same all over. Subclass from an OLE session, create a simple procedure and compile the prg as a dll. VFP provides a tool kit for working with and publishing XML services. You need access to a working IIS server. You create a virtual directory, and use the VFP publisher to generate your WSDL, and web service files for your com object into the virtual directory. That is a task that needs careful attention to details, and making sure every setting is exactly correct. You also need to be careful that the IIS directories, and the on disk directories have proper access and sharing set up. I needed to allow access on the directory with the generated files, and the directory with the dll with read, write, and execute appropriately for the web service to work.
I would suggest testing the web service in VFP before going to test it out from server to server. At least you would know that the web services is functional, and would know that any problems would arise from your client code. PHP has built in SOAP functions. I thought I couldn't use them, then realized I was trying on a windows machine. I switched over to the Mac OSX server where SOAP is enabled. I tried both the built in module, and the PEAR module for SOAP. I found the PEAR module just as easy to use, and underlying calls actually made use of the built in SOAP client anyways (IIRC). I went with the built in module. One less thing to worry about.
It's all working now with a basic service taking a string parameter. We are going to send the data accross in XML as well. It does seem rather funny to me to use XML to set up communication to a com object just to pass it some XML. Why not just make a simple listener that takes a variable containing XML in a POST var? Then one side would have to handle things. I think this makes it easier in the VFP world, but it does seem like a great deal of overhead to me.
Now that the SOAP communication was working I moved on to some new tasks of mapping data we collect into the proper format. I have a spec to work off of, and map my data names to 7 digit codes in the spec. There are about 250 or so fields. I tell you it sucks going cross eyed flipping between pages, and screens. Looking from a document to a PGSQL table definition, and trying to figure out the this column named "foobar" is really supposed to be data ID 8000100. Working with a numbered spec like this brought back memories of my earlier career days working at SED Systems in Saskatoon. This current spec is rather small. I remember spec documents for the Space Station project where it was over 100 pages of tables defining codes, ranges, signals, changes and all sorts of other fun things on the test beds. I loved going through them, and comparing to the previous version, and seeing what had changed. ;-)
On the lighter side of things, I have really gotten into drinking port. Marshall likes to drink port with me right? He doesn't like the hangovers though. He started to get scared when the third day in a row I brought a new bottle home with me and said "Wnat some port Marsh?". All he said "Oh God". He had some all the same. It's Friday, I may have to pick up a new bottle on the way home today.
On another drunken Marshal note. We decided to BBQ awesome hamburgers from Thrifty's rolled in peppercorns. He was cooking, and moving cheese burgers from hot grill to plate. Lets just say there is a big splotch of cheese on the patio now. "Andy ... I need more cheese" Needless to say that was his burger. ;-)
Now I'm hungry. ¶ 1:12:00 PM 0 comments
