A URL Parameter Engine (and Rambling about PHP Globals)

I’ve recently been playing around with PHP again, because (a) it’s vastly simpler to deploy personal projects in PHP than any other platform (aside from pure client-side Ajax of course!) (b) it’s so easy to get simple stuff done.

Anyway, one thing I’m doing is creating a RESTful service where parameter crunching is at an all-time high. The ancient way this was done was with magically created globals. i.e. For the URL http://example.com?id=10, you would end up with a global called $id, set to 10. But the more contemporary way to do it is to use a global array called $_GET, i.e. $_GET[$id]. This is considered safer, to ensure malicious users don’t set important globals. And in PHP 6.0, the former way is being obliterated altogether, since the relevant configuration option – register_globals is being altogether removed.

Well, to me, this is throwing out the baby with the bathwater.

This comes down to how you view PHP. For me, if I want to build a massive, complex, piece of software, I will use Rails or Java. So I consider PHP a scripting language and I value concise expression highly. Features like namespaces (to be added in PHP 6) and even OO don’t mean all that much to me in this language. I am much more concerned with syntactic sugar.

Thus, I would prefer to see templates look like this:

  1. Your name: <?= $name ?>

… and not:

  1. Your name: <?= $_GET&#91;"name"] ?>

A little thing, but in the context of a large corpus of templates, each with many variables, it makes a big difference.

So I’m working on a little parameter-processing engine which will let me use the “evil” $globalVar notation, but in a way that requires each script to pass in a whitelist of acceptable variable names. It also has some other value-adds, such as passing in default values. And these default values can be other parameters that were passed in.

(Incidentally, even if I wasn’t building this script, the first thing I would do would be to globally alias $G or to the uglier and more verbose $_GET.)

REST turns the URL into a command line, and this should push web framework developers towards smarter ways of processing parameters. Think Getopts, but for the URL instead of the shell command line. And that’s where I’m heading.