I've just posted another "Data API What If"-style article over on http://groups.drupal.org/. I figured that was more archiveable than my personal blog, but I wager more people read Drupal Planet than a specific g.d.o group so I'm posting the link here as well in a blatant bit of self-promotion. :-)
I am also posting this over to Planet PHP, in case any other exPHPerts have words of wisdom to offer. Hi guys!
Drupal 6 introduced the concept of a theme preprocess function. In short, it allows themes, theme engines, and even modules to step into the theming process and manipulate the variables that get sent to a template. It replaces the older, clunkier _phptemplate_variables() function from Drupal 5's phptemplate templating engine, but serves much the same purpose.
While we can't backport all of that new functionality, it is possible to greatly simplify _phptemplate_variables() in Drupal 5 in a way that looks a lot like Drupal 6. Specifically, we can break up _phptemplate_variables() into separate functions that act like a theme's preprocess functions in Drupal 6.
The day is nearly upon us! Drupal 7 will open up developers to PHP 5 functionality when it is released next year. Already, there is talk of how, and if, to leverage PHP 5's object handling now that we don't need to deal with the weirdness of PHP 4's object model. Of course, because it's Drupal, our army of performance czars want to know just what the cost is for object handling, and especially advanced object magic like __get(), __call(), the ArrayAccess interface, and so forth.
So let's find out. :-)
One of PHP 5's coolest features is the Standard PHP Library, or SPL. If you're operating in an OO way, SPL is a great way to easily leverage a huge amount of functionality.
Of course, the main problem is that the official documentation on it sucks. At best it points to an off-site series of class hierarchies. (Technically it's not off-site, but not internal to the manual.)
So it's been a week since DrupalCon, which means I'm kinda sorta caught up enough to write about it. Hooray!
As with DrupalCon Sunnyvale, I came away with one conclusion fixed in my mind: The Community is Drupal's greatest strength. Virtually everyone upholds a strong community and open source spirit, and will gladly talk to you for hours about subjects both on topic and off, with or without beer (free or otherwise).
But enough about how cool we are. On with the rundown.
You know you're in a healthy community when people randomly offer limericks in return for code reviews.
And it's especially healthy when it randomly spills over into IRC:
T'was the night before DrupalCon and all through the city, not a hacker was typing, not even a key.
So it's a bit belated, but for those who haven't gotten a phone call from me, you get this instead. Yes, I have made it to Spain alive (and calling the US is expensive, dagnabbit). DrupalCon starts on Wednesday, so in the mean time I am doing my best to uplhold the image of the stupid American tourist.
I will spare you the daily blow by blow, as this isn't that sort of blog, but I will make a few comments on the wonders of international travel...
The schedule for DrupalCon Barcelona has been posted! Not surprisingly both of the sessions I submitted were accepted. If you're coming, stop on by! Now I guess I need to actually put together presentations for them...
There has been some discussion recently, in IRC, issue queues, and blogs, about the Drupal 7 database API and its impact on supporting different database engines. While I am still trying to avoid large amounts of public distraction, especially when we're supposed to be trying to get a Drupal 6 beta 1 out the door, I feel it's important to get a few points cleared up lest they lead to confusion later.