The Berkeley Drupal User Group's March meeting was a week and a half ago, but I'm still thinking about it, and now, in the "better late than never" spirit, I'm writing about it.
First up was Dmitri Gaskin's presentation on the Context, Spaces and Features modules. Development Seed has made these an integral part of their work process, and they gathered a lot of buzz at DrupalCon. Of the three, Context is by far my favorite. It lets you lump various paths on your site into "sections" and assign a context for each section to operate in. In other words, you can tell Drupal that "if the user is looking at a path that starts with 'blog', or they're looking at the profile of a user in the 'blogger' role, they're in the 'Blog' context". A custom module can take that contextual information and react to it by, say, changing the theme or the block configuration.
What's great about this is that it continues the pattern established by the introduction of menu_get_object() in Drupal 6. That function maps paths to the objects that the handlers for those paths are going to work with. With menu_get_object(), developers can write functions that work with the current node or user without knowing where in the path the node/user is specified. It gives a basic context for the menu handler. The context module lets you set arbitrary variables for your context, so that modules can get more information about the page request without worrying about how that information is gathered.
To be honest, I'm less sold on the utility of Features and Spaces. I'm certainly interested in pushing the envelope with regard to packaging up features from sites and automating repetitive tasks, and I think this cluster of modules will be great for a certain type of developer. At the same time, my interest in these modules is mostly academic, since they don't strike me as being very useful for Trellon's particular modus operandi. We don't recycle very many features across clients, and for those we do recycle, it seems that the time needed to customize features would negate the time saved by automating their installation. I think I need to play with the modules a bit more in order to really understand where they fit into our development ecology.
After that, Tao Starbow showed off version 2 of the Popup API module. Tao's done some very impressive under-the-hood work there to enable things like multiple popup forms. The module began as a way to speed up logins and confirmation dialogs, but has blossomed into a powerful AJAX API for making complicated forms more usable. Tao's example was a CCK-based content type that used nodereference to associate with other content types. If, when creating the node, the content that you want to associate it with doesn't exist yet, an extension to the popup API will allow you to create the node in a popup, and then reference it after it's been created. If you want to see some of this popup goodness appear in Drupal 7, check out the patch that Tao submitted, which turns confirmation dialogs into user-friendly popups.
All in all, it was a great meeting. The next one will be at noon on April 23rd, so if you're in the Bay Area, stop by!