PHP was designed with the reverse in mind. In its first release, it could have been considered to be a DSL for web-based applications. It was written to specifically address the needs to writing web applications, and is now building toward a more general purpose language. In all likelihood, this is the wrong way around. It certainly does not fall into the bottom-up design Shangri-La of which Paul Graham is such a proponent.

In reality, though, web-based applications are driving the industry. PHP is still very relevant in that domain. From very early on, PHP was centered on functionality that is considered basic to any web-based framework. Functionality without which each library is simply a thin wrapper over CGI. Features like easy access to GET and POST variables, session handling, header control, and database access have been built into PHP from, if not the beginning, then close enough that dinosaurs like myself don’t remember it ever being otherwise.

PHP has its own share of frameworks, too, which allow the programmer to painstakingly map SQL schema to XML or vice versa. They carefully abstract the logic out of the view and force the programmer to jump through hoops to write a simple application (although, for complex applications, this often makes the programmer’s life *much* easier.)

PHP does not need any of this. In fact, the most pragmatic framework I have used to date for PHP is the Simple PHP Framework, which is just a set of useful classes to automate some of the more tedious areas of web development. What it does not do is get in the programmer’s way. It is Occam’s razor at work in the world of web development. From the SPF website, quoting a non-existent link:

“All the web frameworks in the world won’t turn a shitty programmer into a good one.”

What PHP is not is elegant. It does not have beauty of prose, nor those features that make languages like ML and Lisp so exciting, such as closures, functions-as-objects, or lazy evaluation. Instead, PHP is, above all, a practical language. Instead, it has less sexy features, such as built-in support for XML, XSLT, and Xpath, support most databases, and the built-in ability to serialize to and from JSON and cookie strings.

It is easy to overlook how simple PHP makes many tasks that are complex in other frameworks. For example, Django’s form library is large and complex. I’ve no doubt that most other frameworks have equally Byzantine systems for developing reusable forms. In PHP, one might just write:

function input($type, $name, $display, $value)
{
    < ?
        <label>< ?= $display ?>
        <input type="<?= $type ?/>" value="< ?= $value ?>" />
    ?>
}

The function could be refined to separate the template and the code by putting the HTML into a separate include:

function input($type, $name, $dispaly, $value)
{
    include 'templates/input.inc.php';
}

Simple, right? Which is not to say that PHP’s faults are not legion. That said, I think that PHP sometimes does a better job of building toward general purpose programming than many other languages do of building toward web development.

Submit article

The problem

I recently worked on a project with a backend using the Django admin library. It is a wonderful tool, but the filter interface is not equipped to deal with the thousands of options that were being populated in this particular form entry (a necessary parameter of the project.)

The Django filter interface would take 30 seconds or more to load the multi-select’s data on each form load, even on speedy computers. Moreover, the search filter breaks up queries at spaces, then performs a substring search for each token for every option in the select. Suffice it to say that this locked up more than a few browsers in our testing.

The solution

My first thought was to create my own search using a ternary tree or trie to index the data, but building these structures turned out to be extremely slow implemented in Javascript, taking even more time than the Django filter to initialize.

I ended up trying what seemed like a foolish idea. Create one large string to search by joining all of the options’ labels together (and delimiting with pipes). I assumed this would take a huge amount of memory, but in fact it took less than Javascript trees and was much faster than operating directly on DOM nodes. By delimiting the strings, a bounded regular expression could be used to perform reasonably fast searches of the data. There would be the need to identify the options to which the strings originated, for which I created a simple hash mapping option label to value.

This solution has two main problems – it assumes that all entries in the select box have both a unique label and a unique value, and no label can have a pipe in it. However, assuming that these conditions are met, this solution seems to work pretty speedily, and without overtaxing the browser.

The code

This code is implemented as a jQuery plugin. It hides the select and changes made to the widget automatically update the select. A search box and two lists are inserted into the document; the user enters a partial match in the search box and hits return. The first list is populated with the search results. Double-clicking on a result copies it into the second list.

Items that are already selected are automatically put into the second list. Regular expressions are permitted, and must be surrounded by forward slashes.

This module has been lightly tested in Firefox 2 and 3, Safari (latest), Opera (latest), and IE 7. A few concessions in favor of efficiency have been made at the expense of clarity (mainly for IE, which seems to have the slowest Javascript engine), primarily in the SelectMap constructor. jQuery’s each method and string concatenation proved to be too much for IE, so they were replaced with a for loop over the select node’s legacy options array. Iterative string building was replaced with Array.join, which is faster (but more expensive in memory) in IE.

To use it:

$(function() {
    var select = new BigSelect('target_id');
    // or...
    $('#target_id').bigSelect();
});

The code is available here. You can see a live example here.

Submit article