It’s about time I continued this thing, no? I put Part One up back in May last year, after all… While the IIS+PHP hosting environment I talked about before has remained the same, over time I have continued work on the little page I bootstrapped back then. The page provides the exceedingly simple function of displaying the results of a SQL query.

Part Two! Battling through the vast veils of procrastination, finally our dubious developer brings forth their middling web page!

I don’t know how useful something like this is to the world at large, but here we have it. It’s over on GitHub, now. Do have a look, if you must.

Now, this is about the place where I might talk about the great, arduous journey of self-education I went through putting this thing together. Well… I won’t deny there was a journey, because there most definitely was, but do you have any idea how much of a pain in the ass it is to keep track of just how I figured out the very bits and pieces I used? I put about seventy to eighty percent of this thing together at least more than six months ago. Since then I’ve been tweaking and figuring out improvements. And some of those things I do remember…

Like the improvement that allows for a user of the page to enter multiple search terms to fetch query results for those multiple things. This was a desired functionality for us, and I eventually put it together in what might be a strange way… I’ll bet there are cleaner implementations, but oh well. What I ended up doing was reading the user’s search terms (separated by spaces) and exploding the whole term in an array of individual terms. I then perform a query for each element in the array. I did it this way because it was easier to leverage the existing code that identified when a term returned no results. It is easy to have SQL a query return multiple lines, but terms that aren’t found are not pointed out in the results. In the interests of user-friendliness, I wanted to tell the user which of their terms returned no result. And making an individual query for each term was the easiest way to do that, because my code already had a section to tell the user if their query got no result. I just needed to modify the message to list the ‘no results’ in case there’s more than one. The alternative (to my mind) involved a whole new deal of comparing the original query with the information returned, and identifying the discrepancies. Which reads like a simple thing, I’ll give you, but so far I haven’t felt a great desire to wangle that string manipulation. It probably would be more performant though (only one request would be sent to the DB and I’m pretty sure the string comparisons would be computationally cheaper).


Let’s see, what else… The results of the DB query (or queries) are returned as an array. Very recently I figured out how to programmatically loop through the key-value pairs of that array to print the headers and data of the HTML. It’s real dead simple-like and a Real PHP Developer would probably have a fair chuckle at such a simple revelation, but it was a nice find for me. It’s also key to me being able to release a generic-enough version of this thing that can be used to display the results of whatever query to whatever database, because I wouldn’t want to put this up if it required you to go manually populate the data headers and all that for the table. It just wouldn’t feel complete, you know?

And that’s that for now. I can tell you that Stack Overflow questions were helpful (as always). As were the manual pages. And probably many other sites that were opened in a flurry of tabs as I checked some or other thing, found answers, and systematically closed them all again as I progressed to the next thing.

At some point I would like to summarise the flow of the code and run through what does what and where, but that’s probably more suited to going right on the GitHub repo.