An alternative way of structuring features for distributions

Tuesday, July 12, 2011 - 13:16

Separation of concerns is generally a good concept when it comes to software design. CSS separates presentation from HTML and themes separates presentation from modules. Two very common implementations of that idea. This should of course also apply to how we structure our features...

Drupal distributions are good. They let you get started quickly with a set of configured modules and most often a theme that fits well into the setup. But a common problem many projects run into, is the ability to extend distributions without hacking core. With hacking core in the context of distributions I mean modifying default views, panels, image presets etc. This leads to the exact same problem as if you hack Drupal core - you end up with your own forked version that is hard or impossible to update.

So, why is this? The reason why I think it's hard to extend distributions is the way we are structuring our features. The Kit specification says:

A feature is a Drupal module that provides a collection of Drupal entities which taken together satisfy a certain use case. Example: a gallery feature provides a gallery view, a photo content type, and several blocks allowing a user to add new photos and browse those submitted by others.

Looking at the example above, we are mixing presentation (views, blocks) with data and business logic (content types, fields) in one feature. The line between presentation and data and business logic is extremely fuzzy, I know. Views certainly contains business logic and content types certainly contains presentation. But let me give you a few examples:

  • A feature containing content types and fields are easy to extend - you can export fields to a content type from another feature
  • A feature containing views are impossible to extend - you can't add fields to a view from another feature
  • A feature containing panels are impossible to extend - you can't add panes to a panel from another feature

So if you want to extend the content types, it's easy. But it's not easy if you want to change the presentation. So, what we are trying to do in the new Drupal 7 version of NodeStream, is to separate concerns as much as possible.

Example of core features in NodeStream:

  • Article contains a content type, fields and a few modules providing workflows in the backend. Doesn't present anything on the web.
  • Blogs contains content types, fields and a few modules providing workflows in the backend. Doesn't present anything on the web.

Example of presentational features in NodeStream:

  • Web channel contains views and panels presenting Articles and Blogs on the web.
  • RSS channel contains views presenting Articles and Blogs in RSS feeds.

Disabling the Web channel feature and building a customised presentational feature is now possible leaving the Article and Blogs features intact. You can now take advantage of updates to the distribution on that level at least. After all, we found people choosing NodeStream because of the smart configuration of modules, backend features, workflows etc. They most often want to rebrand and change the presentation anyway.

I'm not saying that the Kit specification is a bad thing. I'm, just saying it doesn't necessarily fit distributions, which it also states under the chapter Distribution features:

Some features cannot comply with this specification and should not aim to.

So, this is how we are trying to make our distribution features easier to extend.