Web development

There has been some discussion in recent days regarding Object-Relational Mappers (ORMs), Drupal, and why the latter doesn't use the former. There are, actually, many reasons for that, and for why Drupal doesn't do more with the Active Record pattern.

Rather than tuck such discussion away in an issue queue, I figured it better to document a bit more widely.

According to Drupal.org, it has now been four years and five days since I first joined the Drupal community. My how time flies, and how much has changed since then.

As Drupal gets bigger and bigger in the marketplace, it is moving into areas where system administrators still hold sway. Dedicated servers or server farms have a different set of needs than a shared host when it comes to monitoring and performance.

That's not even Drupal specific. For any high-end web app, it's useful to be able to interact with it for administrative purposes through standard system tools. On Windows, that's the Windows Administrative Tools or IIS. On LAMP, that could be a unified web app like webmin or a KDE control panel plugin or a Gnome applet. Getting a web app into certain organizations requires offering existing sysadmins a way to integrate it into their existing management workflow.

But what pieces of the app do sysadmins want in their existing admin tools? Calling all sysadmins, what do you want from us? :-)

One of the major changes in Drupal 6 (where "major" is defined as "worthy of a mention in Dries' keynote") was a new feature of the menu and theme hooks. The newly introduced "file" and "file path" keys in those hooks' respective retun arrays. allow them to define files that get included conditionally, only when needed. In theory, that should be a big performance boost; page handlers are virtually never called except for on the page they handle, so loading all of that code on every other page is a waste of CPU cycles. Of course, there is also the added cost of the extra disk hit to load that one extra file we need. Modern operating systems should do a pretty good job of caching the file load, but that may vary with the configuration.

So just how much benefit did we get from two dozen fragile patches that were a glorified cut and paste? And is it worth doing more of it? Let's benchmark it and find out.

For those who haven't really been following it, several hundred contributors, 13 months, and tens of thousands of lines of code have gone into making the only version of Drupal ever that is better than Drupal 5. So, naturally, we've released it and called it Drupal 6.

Drupal 6 boasts a boat load of new functionality, ranging from Ajaxy yumminess throughout the system to native support for OpenID to vastly enhanced multi-lingual support. Several entire subsystems have been either overhauled or totally rewritten to proivde more power, flexibility, and speed. The official press release has the complete rundown, or for the more visually inclined there's a new features screencast. For me, though, the new theming system is feature numero uno.

Marco Tabini, of php|architect magazine fame among other things, has been openly disappointed at the death of PHP 4. Not because he likes PHP 4, but because of the "OMG you're discontinuing something that everyone's still using!" argument.

I like your magazine, Marco, but I have to disagree with you on this one. :-)

Earlier this week, the PHP team released PHP 4.4.8. Baring any major security holes between now and August 8th, it will be the last release of PHP 4. Ever.

We are also one month away from the GoPHP5 deadline, after which any new releases of almost every major PHP project will require at least PHP 5.2. If you or your web host is running an older version, you are going to run into problems.

The future is neigh. Is your server ready?

A ran across this article recently making the rounds. In it, the author discusses spending 2 years in Ruby on Rails land before finally giving up and coming home to PHP, wiser for the experience. It's a good article, but one thing in it really raised the hair on my neck.

PHP is, conceptually, a very traditional language. By that I mean that it is steeped in the C/C++/Java mindset of how a program is put together, rather than the LISP/Javascript/Ruby/Python mindset. That's not a bad thing, necessarily, but it does mean that a lot of the cool dynamic language capabilities in those languages isn't really available to PHP developers. I freely admit to being jealous of functions as first-class objects, for instance.

PHP 5, however does include lots of "magic" capabilities, some in the object model directly and some via SPL Interfaces, that, if used properly, can make up for a lot of that lack of dynamic capaibility. A favorite of mine is the ability to add methods to a class at runtime.

What? You didn't know PHP can do that? Well, that's because it can't. However, we can simulate it pretty closely if we're careful. Let's see how.

Are you tired of hearing me talk yet? If not, why not come work for Palantir.net? We're looking for a PHP/Drupal programmer and a web developer/themer. Benefits include a full time position at a small business in Chicago, working on sites for higher education, not-for-profits, and other non-evil clients, a company issue Nerf gun, and access to the company Wii. And getting to work with Larry! Who could ask for a better job?