Blog

The Three 'M'-igos

Wed, 11 Oct 2006 19:29:00 PDT

Happens all the time, right? One minute you're cranking out line after line of quality code then the next it all comes to a screeching halt for no apparent reason. I immediately go into troubleshooting mode. A quick and simple redirect using a header("Location: ...") function should pose no danger of messing up my app -- but today it did.It kept throwing me to a "Page Not Found" message and, since it was technically only moving me to the exact same script, I couldn't see why. For such a simple line of code to push things so far out of whack seemed preposterous. Well, it's always good to check your digital ego at the door and go through it all rationally.Here's how I thought this out:the redirect tossed me to the same script yet gave me a "Page Not Found"any GET variables I passed were fine and weren't even being relied upon heavilythe server was running fine since the previous and other pages were displaying just fineI was redirecting to the correct URL -- wait a minute!Turns out I wasn't at all. I was routing the script from comments.php to commments.php and that just ain't right. I suppose when you have so many of the same characters in a row the brain tends to skip over them once in a while. Whatever the reason, it took me a few minutes to catch and I just had to chalk it up to another hard lesson learned since I neglected to believe in Occam's Razor. Next time, I'll check to see if it's spelled correctly first.

A Piece of Query Cake

Fri, 13 Oct 2006 10:59:00 PDT

If you've ever created SQL queries with PHP, you probably know what a pain it can be to create insert and update statements. I really, really (really) don't like it. As I was working on my personal site, and exploring possible frameworks to use, I came across CodeIgniter. They have a great database interaction library, especially the function for creating the insert queries.Today, armed with only the descriptions of CodeIgniter's query helper functions, I spent 20 minutes trying to duplicate some the effect of the insert and update functions. I've never seen the code, or even used it, but I didn't have to see the code to write a similar function. Both functions take a table name and an associative array of column names and values. The update function also requires a WHERE statement, and it can't be blank. This is different from CodeIgniter, and that's so you don't accidentally reset all of the passwords in the mysql users table, or any table for that matter. And then, *poof*, the function gives you a nice sql statement.I'll never have to write another "INSERT blah blah blah" again. Yay!<?php/** * Generates an insert sql query from the parameters * * @param string $table The name of the table * @param array $array An associative array with the values similar to column=>value * @return string The sql query */function getInsertSQL($table, $array) { $sql = 'INSERT INTO '.$table; $columns = ''; $values = ''; foreach($array as $key => $value) { $columns .= $key.', '; if($value != "") { $values .= "'".addslashes($value)."', "; } else { $values .= "'NULL', "; } } $columns = substr($columns, 0, -2); $values = substr($values, 0, -2); $sql .= "($columns) VALUES ($values)"; return $sql;}/** * Generates an update sql query from the parameters * * @param string $table The name of the table * @param array $array An associative array with the values similar to column=>value * @param string $where What to limit the update to. Cannot be blank. * @return string The sql query */function getUpdateSQL($table, $array, $where) { if(trim($where) == "") { return; } $sql = 'UPDATE '.$table.' SET '; foreach($array as $key => $value) { if($value != "") { $sql .= $key."='".addslashes($value)."', "; } else { $sql .= $key."='NULL', "; } } $sql = substr($sql, 0, -2); $sql .= " WHERE $where"; return $sql;}?>

Cross Table Content Search

Fri, 27 Oct 2006 11:34:00 PDT

One of the more interesting adventures working with data storage is trying to aggregate information meaningfully from multiple very different data structures. Imagine you've got a website filled with content (say, a few hundred pages). All the content is stored and output dynamically - who wants to create and maintain 500 static html pages, anyway? And of course, you need a bit of variety, so all this content is spread across five different page designs, each requiring its own template and data structure.Now you say you want to search your site? All the content? And you want the results all together in one big happy sorted-by-relevancy list? How on earth am I going to do that?Well... like this.BackgroundOur basic data structures are pretty well cemented for dynamic front-end content. Every page has an entry in a core table (we'll call it page). The page entry has all the data that is universal. ID number, meta information, title, as well as parent and order numbers (for navigation hierarchy. In addition, we have a template id and a content id.The template id points to an entry in page_templates. Here you find the template names and, more importantly, the content table names. Remember that each template needs its own table as content block layout varies. With content table name and content id handy, you can leap to the actual page content.The SearchSearching a single table's content is a relatively easy matter. Put a FULLTEXT index on the relevant fields and runSELECT idFROM tableWHERE MATCH(search_columns) AGAINST (search_string)Since you designed the table, you know what fields to search on, right? Heck, this would work even for multiple tables. Just loop through the searches, writing a custom set of search indices for each straight into your queries.This is all well and good when you're working on a search for a single website. But working for a fairly prolific development company, who conveniently use the same basic table layout for the vast majority of their content managed front-end sites, the smart move is to write a function that discovers these indices on its own. This can be achieved using SHOW INDEX FROM content_table. From there, parse the relevant indices like so:while($row = mysql_fetch_assoc($res)){if($row['Index_type'] == 'FULLTEXT'){$search_cols .= $row['Column_name'].', ';}}Stick $search_cols up there in your single-table search, and suddenly you've got a dynamic FULLTEXT search that you can use on any table.Aggregating the DataUnfortunately, on a seven template site you've still got seven different sets of search results. The FULLTEXT search will return each result set in weighted order, but the user doesn't care what's using what template. They want the whole list to be in weighted order. To handle this, I tossed in a bit of array processing. First, restructure the query a bit to actually return the weight value itself: SELECT id, MATCH(search_columns) AGAINST('search_string') AS weight FROM content_table WHERE MATCH(search_columns) AGAINST('search_string')I ran this for each content table, and appended all the results onto a single array. From there I just wrote a simple php usort comparison function to sort on the table weight (and obviously the queries were expanded a bit to draw some actual useful information, beyond just the page id).Of course, with anything that works, the big question is always "How can I make it better?" So... how can I make it better? Right now our production servers are running MySQL 4.0 (to paraphrase Peter Zaistev, as long as it works, why put a whole lot of data in danger for an upgrade that isn't necessary?). I've got some notions regarding putting more of the load on the database side, but those will take stored routines (5.0) and/or subqueries (4.1). But with where we're at now, does anyone else have a notion of how to improve this solution? Or perhaps a completely different solution to the same problem?

File Extensions

Mon, 16 Oct 2006 12:57:00 PDT

I've been using a fairly complicated function to grab the extension of an uploaded file. I have run across many instances where I have wanted to split up the file name from the file extension, or just find the file type. Since MIME types are not reliable enough for grabbing a true extension, I have been using this aforementioned function.The following is a snippet of code that I had been using to retrieve the extension of a file:<?php$filename = 'image.jpg'; //name of file$nombres = split('.', strtolower($filename));$nombre_start = '';for($k=0; $k<count($nombres)-1; $k++){ $nombre_start .= $nombres[$k]; }$nombre_ext = $nombres[count($nombres)-1];?>However, there had to be an easier, cleaner way to get this information. So here is the code I came up with the following code for retrieving the extension of a file:<?php$filename = 'image.jpg'; //name of file$ext = substr(strrchr($filename, "."), 1);?>In this case, printing $ext would give you "jpg".Grabbing just the filename was a bit more involved, but still relied on the same principal:<?php$filename = 'image.jpg'; //name of file$name = substr($filename, 0, strpos($filename,substr(strrchr($filename, "."), 0)));?> In this case, printing $name would give you "image".

Printing without the Dialog

Mon, 09 Apr 2007 16:36:00 PDT

One day, one of our clients came to us with a very unusual request - they wanted to be able to print something directly from the browser, but without displaying the usual print dialog box. I don't have much time in the webdev business, but I've never heard of this kind of request, and neither had anyone else in the office.Initially, we didn't think that it was possible. The browser File > Print command uses a dialog box. So does the javascript print() function. The only reason that we knew this was possible was that the client's current system was already doing it. With a little research, we figured out how to print directly from the browser without displaying a dialog box.Tools you'll need:1 local Unix or Linux serverA pinch of Javascript1 PHP exec() callPHP to format your dataFirst: your server MUST be a local server, on the same network as the printer. This is because we'll be using the lp command to shoot off the print job.Second, to get this to work from the browser, you need a little javascript to call a file using XMLHttpRequest that will call the lp command and execute the print job.The actual command to start off the print job looks something like this: lpr -p printer file.txtThe final ingredient of this system is to use PHP to format the data you need to print, and then save it to a file. The lpr command then works on that file.In the end, we were able to get this whole thing working, but only because Dustin over at out co-location facility knew what needed to be done. Part of the command line printing involves manually creating a print spool - a task not for the faint of heart. The spool is defined in /etc/printcap, and looks something like this:printer:\ :ml=0:\ :mx=0:\ :sd=/var/spool/lpd/printer:\ :af=/var/spool/lpd/printer/printer.acct:\ :sh:\ :rm=XXX.XXX.XXX.XXX:\ :rp=text:\ :if=/etc/magicfilter/ibmpro-filter:\ :lpd_bounce=true:Replace the XXX string with your printer's IP address. Then, when you click on a print button, the javascript fires off the XMLHttpRequest, which calls the PHP script to create the print file, and executes the command to print that file. Or, you can call the script with a PHP function on a page load.Shout outs to Dustin and Andrzej, for making the printing work, and for getting the scripts to call the print action.

The Joys of Object Oriented PHP

Wed, 08 Nov 2006 13:36:00 PST

It's pretty common for PHP developers to make complex and difficult to maintain scripts, and I am no exception. I write my code in two distinctly different ways: scripts that do a whole bunch of things depending on input, and classes that do a bunch of things depending on how they are called, but from lots of different scripts. But which is better? It's a nice ego boost for any prrogrammer to know they created a script/function/class that is really useful, and well designed, but at some point the code stops being well designed, and becomes gross. I think that point is when you have one script that displays an entire (SQL) table of data, views a particular row, edits that row, can delete that row, or can add new row to the table.If my Software Engineering professor sees me doing that, I imagine that he'll reevalute my grade in his class.The first version of my coding style (a script that does everything), generally looks like this (psuedo code for the sake of brevity): check permissionsif edit request sent create edit sql query databaseif delete request sent create delete sql query databaseif add request sent create add sql query databaseinclude header html fileif adding a new row display blank html formelseif editing a row display html form with values filled inelseif viewing a row display row previewelse display all rowsinclude footer fileSome of you out there might be copying that down to use in your own code, and I don't mind at all. That kind of structure is easy enough to work with when you only have four or five columns for data, but as you get more and more complicated data structures, and incorporate more and more tables into this style, using files like this can get extremely difficult. There is a better alternative, and that is using Object Oriented PHP. You create a control class for each table of data, and call its seprate methods to perform the tasks you want to accomplish. CodeIgniter gets this design spot on, as each class and function is also translated into a url. For example, if you have a Library class and you want to call the preview method, you would simply point your browser to www.mysite.com/library/preview. My designs aren't quite as good as CodeIgniter's, but they are good (the reason that CodeIgniter is able to have such good url's is due to some pretty complex File Not Found processing). Here's an overview of my classes:class something variables according to the columns in the table function load (id) queries database for the row that has the specified id assigns the values to the classes' variables function save () takes the variables from $this and creates an sql statementand so on as I need. For each different script, I name it something_save.php or something_view.php, where the first word is the class, and the second is the function name. Somethings I leave up to the php file, like xhtml templates and style, but all I have to put in those files is two lines of PHP code: load() and the function call. This makes the control logic of components of your application really easy to use, and also is better from a Software Engineering view.I hope you can implement this methodology into your own coding, and I welcome comments on how to improve this idea.Disclaimer: I left out a lot of details on the psuedo code, for several reasons, but mainly because I wanted to talk about a concept, rather than a tutorial.

Use Functions for Readable Code

Fri, 01 Dec 2006 08:41:00 PST

On my way to meeting with a client, I got into a conversation about using functions in your code. One of the guys learned to write assembly first, and so his stance was that creating functions was only feasible when you used the same code more than (about) three times. That view makes a certain sense - don't deal with the overhead of creating tons of functions for stuff you'll seldom use. I argue that you should use functions where ever possible, first because it makes code easier to generalize (and thus re-use), but also because it makes code much more readable. To illustrate my point, here are two fictional but entirely probable examples. And here's some guidelines: Whitespace does not count as a line, but { and } do.Only lines of code that are unique to the specific example will be counted, because if you can use 8 lines of code by writing one, it's really only one new line of code.Statement format is consistent throughout - that means that if I condense 3 statements into a single line of code, condensation is done universallyExample 1: Get All Rows From a Table The Assembly (aka Code Soup) Way:$sql = "SELECT * FROM table";$result = mysql_query($sql);if($result) { $rows = array(); while($row = mysql_fetch_array($result)) { $rows[] = $row; }}That's pretty straight forward, and takes 8 lines of code. Pretty simple, and easy to understand for most programmers with experience. The main drawback is that code is only useful in that one situation.Now my way:$rows = getRows('table');function getRows($table) { $sql = "SELECT * FROM $table"; $result = query($sql); return fetchAll($result);}function query($sql) { return mysql_query($sql);}function fetchAll($result) { $rows = array(); while($row = fetch($result)) { $rows[] = $row; } return $rows;}function fetch($result) { return mysql_fetch_array($result);}There's 19 lines of code in this method, however only one is unique to this situation (the first one - all the functions can be reused). This method is also readable by just about anyone including your boss (ok, so maybe that's not really a good thing). It's also terrifically easy to maintain and extend this code. True, in two cases (query and fetch), I'm just renaming PHP functions, but that makes them so much easier to type, it's worth doing to save time.Example 2: Displaying input fields for a form in a tableThis is a pretty common occurrence in web development. Let's say you want to create a form, and use a table to format it on the page nicely. We know that designing with tables is bad, but sometimes it happens. We'll have four fields in our table: a text field, a textarea, a file input, and a textarea following that. Think of this as a heading, some text, an image, and a caption for that image. Here's how the Code Soup version might look: (I've left off tag attributes except input types for brevity's sake)echo '<form>';echo '<table>';echo '<tr><td>Heading</td><td><input type="text" name="heading" /></td></tr>';echo '<tr><td>Content</td><td><textarea name="content"></textarea></td></tr>';echo '<tr><td>Image</td><td><input type="file" name="image" /></td></tr>';echo '<tr><td>Caption</td><td><textarea name="caption"></textarea></td></tr>';echo '</table>';echo '</form>';That's 8 lines of code, all legible and usable. But we can do better. Notice that we have two textareas, and the only thing that changes between them is the name of the field. We can generalize this, and also make that fragment much more readable, like this:echo '<form>';echo '<table>';echo inputRow('Heading', 'heading');echo textareaRow('Content', 'content');echo fileRow('Image', 'image');echo textareaRow('Caption', 'caption');echo '</table>';echo '</form>';function inputRow($label, $name) { return '<tr><td>'.$label.'</td><td><input type="text" name="'.$name.'" /></td></tr>';}function fileRow($label, $name) { return '<tr><td>'.$label.'</td><td><input type="file" name="'.$name.'" /></td></tr>';}function textareaRow($label, $name) { return '<tr><td>'.$label.'</td><td><textarea name="'.$name.'"></textarea></td></tr>';}Again, the functions use slightly more lines of code than the Soup version, but there are two huge benefits from using functions. Number one is increased legibility, and number two is reuse. The main code block that uses functions is a whole lot easier to work with than the one that doesn't. Also, you can use those functions anywhere on your site, and get rid of the overhead of writing out '<tr><td>...</td></tr>' every time you just want to add a text input to the form. I used this same method to shrink part of our CMS from ~700 lines of code to less than 100, and it's a lot easier to modify now.Properly using functions and classes can help your coding a lot. It can speed up development, make maintenance easier, and even help you make better software. So go function crazy. If you create a function that makes your life easier, try to make that function even easier to use. But remember, functions shouldn't do two (or more) different things. If you have a function that updates a database and prints out a page template, split it into two functions. Also, never, never ever declare a function in multiple places in the same project. If you have many instances of a function to update a database, or capture form submissions, it totally defeats the purpose of making functions in the first place.