“Spaces 3 has vast improvements but it continues — per mission — to screw with your mind :-)” — Alex Barth

Over the past few weeks we’ve been working on an experimental branch of Spaces that we’re now ready to call Spaces 3. Spaces is an API module that allows you to treat different facets of your Drupal site as its own customizable environment. It is at the core of Open Atrium’s group structure, allowing each Atrium group to customize what features it has enabled, their access settings, theme colors, and other settings.

Previous versions of Spaces have required site builders to tailor their features and settings specifically for use with Spaces. Spaces 3 changes all that, placing Spaces as a mediator directly between the configuration APIs of Drupal and the storage of their configuration. This means that Spaces 3 makes it possible, theoretically, for nearly anything in Drupal to be configured per space.

The anatomy of Spaces overrides

Spaces stores its overrides in a normalized overrides table. Here is a sample row from the spaces_overrides table:

`+------+----+-------------+----------------+------------------+
| type | id | object_type | object_id      | value            |
+------+----+-------------+----------------+------------------+
| og   | 14 | variable    | comment_blog   | s:1:"1";         |
+------+----+-------------+----------------+------------------+`

The type and id columns identify the specific space this override applies to. By identifying spaces by this pair of values it's possible to implement nearly any kind of space. While Spaces provides space types for groups, users, and taxonomy terms out of the box, implementing other types of spaces is totally fair game. On various projects we use per-book spaces and have integration between spaces and our projects on code.developmentseed.org.

Next, the object_type and object_id columns identify the type of Drupal configuration object that the override describes. In this case, the Drupal variable comment_blog is being overridden.

Finally, the value column describes the value for the object in this specific space.

Put all the pieces together and this particular database row in plain English means:

In group 14, commenting is enabled on blog posts.

As a developer, this means that even if commenting is turned off for the rest of the site, when group 14’s space is active commenting will be enabled.

`// Returns 1.
print variable_get('comment_blog', FALSE);`

Individual object type overrides are handled by plugins to Spaces called controllers. We’ve written a controller for Drupal variables and for context. You can expect more controllers in the future (we have some ideas for Views and string overrides controllers), and you may want to check out the API if you’re interested in writing your own.

A new (and old) paradigm for Drupal configuration

The fact that variable_get() or context_load() might return something different depending on your 'environment' can certainly screw with your mind. But it turns out, this idea isn't all that new - in fact, Adrian advocated a contextual configuration system way back in the day.

Spaces 3 takes a big step in the direction of environment-based configuration, but there’s certainly a bigger prize at the end of the journey. While Spaces currently implements up to two levels of overrides per object — a space specific override and possibly a set of preconfigured defaults saved as a spaces “preset” — the possibility of a flexibly stacked number of override environments is enticing. For example, per-language configurations may begin the stack of overrides, followed by per-group overrides, and finally topping off the stack would be per-user overrides.

Fixed stacking model in Spaces 3 (where > can be read as “inherits from”):

space > preset > original

Arbitrary stacking model that allows any number of configuration levels:

space n > space n-1 > ... > space 1 > space 0 > original

This chain of inheritance is very close to being implemented in the current architecture of Spaces 3, but we’re holding off on it for now. More than anything else, the difficulty of making this potentially complex concept intuitive and clear to the user is a real UI challenge.

What’s next

The module refactoring arms race at Development Seed continues, and Spaces 3 is just the next player to up the ante. Expect bleeding edge alpha releases of all of these projects soon. We’ve been working on these projects with Kathleen Murtagh from GoingOn and with our colleagues at the World Bank who are deploying customized versions of Open Atrium, and it’s been great to have their support and their user stories as input to help make these new tools stronger for the community.