How Contexts will rock your Drupal world (and why they should be in core)

In case you've been living under a rock for the past two years (or slaving away in a dark underground lab like me) and haven't heard about Contexts, give me two minutes of your time and allow me to explain why they rock and how they fill some gaping holes in Drupal core. The easiest way to think of Context is like Triggers and Actions for your theme - except instead of Triggers and Actions, you have "Conditions" that define a context and "Reactions" to take when those conditions are met. The archetypal Context is a set of Conditions and Reactions that, if put into English, would read "If the user is viewing a Blog entry, show a block listing the immediately adjacent entries." This might sound like a trivial example just as easily accomplished with Panels or (gods forbid) core Blocks rules, so let me give you a more compelling and personal example. For better or for worse, a lot of websites serve dual purposes: a public-facing side serves to disseminate information, garner publicity, etc..., while a protected area serves as an intranet, with tools for project management, team calendars, etc... (think Open Atrium). Security concerns aside, I think this is a setup that works very well in a large number of (ahem) contexts, as it allows for easy sharing of data and resources and graduated escalation of privileges and access to those resources. The problem is that what you want a prospective client to see when linking in from a Google search is drastically different from what you want to see while managing tasks and projects, and is different still from what you want to see while building out your site. (In case you haven't figured it out, I'm talking about you and me here!) For instance, I really don't want to look at a banner taking up 1/3 of the page while I'm trying to manage my projects (although I think it's a perfectly acceptable trade-off to sacrifice that space in order to engage visitors). I also don't need to look at my own copyright notice when I could use that space to list high-priority tasks. But I don't want to just change my theme, because I need to be able to easily see what my homepage and other sections will look like for anonymous visitors (and it's a minor but frequent hassle to open up new browser windows using add-ons like MultiFox). In the "old days", a solution would be to edit your page.tpl.php (and other templates) and add a lot of conditional statements checking the content type, user type, etc... in order to hide the banner. If you were lucky, your use case was simple enough that you could use core Block conditionals ("Show this block on the following pages...") to take care of the unnecessary blocks. Contexts allow you to achieve the same level of abstraction (defining contexts based on "Conditions") and react to those conditions in much more portable way. In this case, I simply set the Reaction to hide the unnecessary blocks, and add a much more concise and abstracted conditional to page.tpl.php - something along the lines of "if (context_get('context_ui', 'section') == 'admin_area') { // hide banner}". I'm surprised there hasn't been more of a clamor to get Context into core - the way that it so nicely eliminates hacks like that alone makes it deserving of the honor. I also think the way it parallels Triggers and Actions is really motivating. Maybe people like me are just an edge-case - I certainly hope not, but that's a subject for another post :)