I started to just get the data out of the database. That meant having something like this:

require 'php/bootstrap.php';
$rResultset = $oDatabase->query("SELECT * FROM mytable");

Simple enough, right? The next thing to do was decide what format the export should be in. All they said was a format MS Excel can understand, so the simples thing I could think of was the CSV format. And since I had recently used fgetcsv to read some stuff from a csv export, I took a wild guess and typed fputcsv in my editor.

So, I had to take the data I already got from the database, create a csv file, and send that to the user with the correct HTTP headers. Easy enough, that means this:

// Put the data in a file
$rHandle = fopen("export.csv", "w+");
while($aResult = $oDatabase->fetch($rResultset)) {
    fputcsv($rHandle, $aResult);
}
 
// Send the headers
header("Content-type: application/csv");
header("Content-Disposition: attachment; filename=mytable-export.csv");
header("Pragma: no-cache");
header("Expires: 0");
 
// Read the file, from the beginning
rewind($rHandle);
 while (($sOutput = fgets($rHandle, 4096)) !== false) {
        echo $sOutput;
 }

Okay, so that should work pretty well. Unless two people run the export at the same time. Better make the filename unique. Oh but then I’ll get huge load of files in my tmp directory, better delete the file afterwards.

Luckily, at this point, I hadn’t actually written any code, it was all just pseudo-code in my head. Writing to a file just so I can output it, and then delete that file… that’s stupid. (Not to mention a waist of IO, which is expensive enough as it is without me throwing it out the door like this.)

This meant I had a mission: I wanted to output the data right away, but using fputcsv since I don’t want to bother with all the csv stuff myself.

Enter fopen(“php://output”, “w”); which allows you to write to stdout (read: the webserver, read: the browser) as if it where a file. With that, my script became as simple as this:

// Send the headers
header("Content-type: application/csv");
header("Content-Disposition: attachment; filename=mytable-export.csv");
header("Pragma: no-cache");
header("Expires: 0");
 
$rHandle = fopen("php://output", "w");
while($aResult = $oDatabase->fetch($rResultset)) {
    fputcsv($rHandle, $aResult);
}

Rather simple if you ask me. And to think I considered messing with files.

After that, the script needed some tweaking: as first row, they wanted the column names. And “America style” csv (where the separator as a comma) doesn’t work here in Europe, since we use the comma for decimal numbers. Neither of which was a problem:

$bHeadersDone = false;
$rHandle = fopen("php://output", "w");
while($aResult = $oDatabase->fetch($rResultset)) {
     if(!$bHeadersDone) {
          $bHeadersDone = true;
          fputcsv($rHandle, array_keys($aResult), ";");
    }
    fputcsv($rHandle, $aResult);
}

Et voila, it does exactly what the customer wants, its just 29 lines long, and it learned me something new.

Obviously, I started with a search for something like “php generate wsdl from code”.  That exact search gives my over 2m results on Google. To bad non of them had the answer for me. Then, I read somebody directing somebody else in the direction of Zend_Soap_AutoDiscover and decided to take a look myself. It seemed to do what I wanted it to, so I figured, why not have a look at it.

After downloading ZendFramework to my laptop and setting up autoloading for it, the first thing I tried was creating a script separate from my server.php called generate.php. In that script, I included my service class, told Zend_Soap_AutoDiscover I wanted to use that and to handle() requests. Browsed to the file, and voila, I had my WSDL file. So, I saved the file. Then, I found out Zend_Soap_AutoDiscover has a dump($filename) method that can do that for me. Instructed SoapServer and SoapClient to use that WSDL, and it worked!

Well, somewhat. Calling $client->__getFunctions() showed me my functions. But if I tried to call one of them, it threw an exception. After some working, I noticed that the targetNamespace was http://localhost/soap/generate.php, which is plain wrong as I’m calling http://localhost/soap/server.php. Ah, that makes sence – Zend_Soap_AutoDiscover couldn’t have known I wanted to use server.php now could it?

So then I thought, why not put the Zend_Soap_AutoDiscover code in my server.php, detect ?wsdl and give the WSDL in those cases. After first having a small codesnippet in server.php that detects ?wsdl and lets Zend_Soap_AutoDiscover do its thing -which worked- I decided the final step was to extend SoapServer so that it would, in fact, support WSDL generation. (Sure, not native, but for native support it’d need to be done in C, which I don’t know anywhere near well enough to make an appempt.)

So I went ahead and wrote my class, WsdlGeneratingSoapServer (describing names for the win). It didn’t need to do much – just overwrite setClass, setObject and addFunction so that it can keep track of what the SoapServer can do (and then passing on the call to parent::, obviously) and overwrite handle, which should detect ?wsdl and, if found, have Zend_Soap_AutoDiscover do the generating, calling parent::handle otherwise.

Sounds easy enough. And it was, I had the class done in about 10 minutes. And then, I tested it. WSDL generation worked perfectly, so goal accomplished! Or well, not really. Normal soapcalls now result in a SoapFault. So I started to try changing things. Long story short, this simple code caused a soapfault. And since thats crazy, copied that script from my laptop (which has PHP Version 5.3.2-1ubuntu4.2 + Suhosin Patch 0.9.9.1) to my VPS (which has PHP Version 5.3.3RC4-dev) and what do you know, it worked.

I didn’t feel like doing any more PHP tonight, so decided to write this blogpost instead. I’ll try the code at work tomorrow, hopefully it’ll work there as well.

In the mean time, here is the code. If you change new SoapServer(…); to new WsdlGeneratingSoapServer(…); (and have Zend_Soap_AutoDiscover, which is part of Zend Framework), you’ll have WSDL generating abillities, too!

I have been doing a lot more PHP lately then I have in a long while and that, plus the prospect of a pretty big project I will hopefully start on during the summer, made me think a bit about error reporting. I’m not talking about E_ALL vs E_, err, 0. I’m talking about what to tell the user when either (s)he or the application screws up.

As explaining is easier by example, here’s one: your application has a login section which grants access to who knows what. A user wants to log in, has the correct username but the wrong password. Do you simple tell them “invalid credentials” or is it something along the lines of “Sorry, $prettyusername, but the password you provided does not match the one in our database. You may try again[link to #login]. You can also recover your password[link to password recovery]“?
From where I stand, both have there up- and downsides. Just telling them they didn’t enter valid credentials isn’t anywhere near userfriendly, but if the user is someone who is trying to break into the application I don’t want to tell them anything.

So, what is more important, being friendly to your users or giving people that try to break in as little help as possible?