If there’s one geeky web catch phrase that’s defined 2007, it’s probably the much-abused mashup. If you haven’t been trend-watching, a mashup is a web site that wires together data from other well-connected web sites to provide a unique and useful (or at least amusing) service. Take the Twitter.com feeds from all your project’s developers, your Unfuddle.com checkin history, and slap it on top of a Google Map projection: voila! Developer productivity by zip code. That, friends, is a mashup.
True, many examples of the trend are novelties rather than killer apps. The number of people who really, really need to watch eBay auctions appear on a 3D globe in realtime, with gasoline prices in the latest bidder’s home town, is pretty small. Underneath the hood, though, the technologies that make mashups possible are a profound change in how web sites manage and expose their data. More and more sites are exposing their data using simple RESTful APIs and XML feeds, and the new tools in Drupal 6 will make integrating that data into your sites a lot easier.
Three changes in particular may not sound very impressive compared to some of the other flashy features in the new version, but I’ve found them extremely useful. In writing the new Amazon module, Tumblr module, and an upgrade Twitter module for Drupal 6, these three features have saved me man-days of time.
The first change is subtle, but important for developers of third-party modules. Because so much of the Web API data that’s out there is exposed as XML, it’s critical to be able to read and parse XML when integrating with them. In PHP, the simplest and cleanest way to do that is almost always the standard SimpleXML library. It’s been around for quite some time, but has only been included in the standard PHP distribution since version 5.0. While Drupal 6 still runs under PHP 4, it allows third-party modules to specify what version of PHP they require. What does that mean? If you’re developing a module that, say, pulls in the latest events from Upcoming.org, or parses product information from Amazon.com, adding a single line to its .info file will tell Drupal to handle version-checking for you, and prevent users on older PHP versions from enabling it. That leaves you free to use SimpleXML’s easy-as-pie XML parsing. Obviously, that means your module will require PHP 5 – prior to Drupal 6, though, there was no way to enforce that without plastering warnings all over your module’s README.txt, or coding your own version-checks before doing anything important.
The second change is more obvious. Drupal 6 is shipping with SchemaAPI, a new metadata-driven mechanism for defining and manipulating database tables across all database systems. In Drupal 5 and earlier, module developers had to write their own CREATE and ALTER table statements for every module and every supported database provider. Less popular DB engines like Postgres often suffered as devs didn’t have an install to test against. Now, tables are defined as metadata and the SchemaAPI handles creating and maintaining the tables across all providers.
One of the valuable side effects is the presence of the new drupal_write_record() function. If you’re holding onto an object or array with the data for one of your database records, just call drupal_write_record(), tell it the table name, pass in the object or array, and SchemaAPI will build and execute an insert or update query automatically. During development, a module’s database schema can change rapidly as the module is refactored and tweaked. This function dramatically reduces the amount of repetitive SQL that needs to be written for each module, and those sections of code were some of the easiest to get out of sync when refactoring.
The third and final feature is the inclusion of the Actions API. Previously available as a third-party contrib module, it allowed modules to define small, self-contained bits of functionality (like publishing a node or sending an email) in a form that was easy to trigger when other events occurred. There’s a simple module called Trigger that’s part of Drupal 6 that allows actions to be fired when nodes are created or deleted, when users are created or logged in, when cron runs, and so on.
Sites that allow information to be posted and manipulated via their web APIs (like Twitter.com, Unfuddle, and so on…) can easily be hooked up to the Actions API, too. By wrapping a Drupal 6 Action around a Web API’s methods, it’s easy for a site administrator to chain together complex workflows. For example, Google’s hosted application service allows organizations to use Gmail, Google Docs and Google Calendar on their own domain names. The administrative functions for creating and maintaining user accounts are accessible using a Web API. A Drupal module could easily expose functions to use those APIs. And an Action wrapped around the ‘create user’ and ‘delete user’ API calls for Google Apps could be wired to Drupal’s own account creation and account deletion events.
Obviously, there’s still a lot of work involved in building a clean Drupal wrapper around another web application’s functionality. In Drupal 6, though, numerous small improvements have made the process quite a bit smoother. The ability to specify minimum requirements, the convenience of the SchemaAPI, and the easy configuration of the Actions system help make this a very, very promising release.