Jeff Miccolis and I spent some time last week pulling together a proof of concept -- we're calling it the "features" module. Jeff writes:
* Module file for the features module, which enables the capture and
* management of features in Drupal. A feature is a collection of Drupal
* entities which taken together statisfy a certain use-case.
Here is a quick informal screencast of what this thing does from the UI perspective:
What will be of more interest probably to people in the group is the internals of the module. If you're interested, take a look at
API.txt, where I've documented some of the basic concepts for feature component and module dependency detection. The core concept behind features is that you can start from some starting point in Drupal and allow each derivative component to delegate export and dependency detection to its derivatives and so on.
In practice, hook_features_export() has 3 tasks:
1. Determine module dependencies for any of the components passed to it
e.g. the views implementation iterates over each views' handlers and
plugins to determine which modules need to be added as dependencies.
2. Correctly add components to the export array. In general this is usually
adding all of the items in $data to $export['items']['my_key'], but
can become more complicated if components are shared between features
3. Delegating further detection and export tasks to related or derivative
#3 is a key concept in the Features module. Each export processor can
kickoff further export processors by returning a keyed array where the
key is the next export processor hook to call and value is an array to be
passed to that processor's $data argument. This allows an export process to
start rather simply, at a single object:
And then branch out, delegating each level of branching to its
| | |
[node] [block] [views]
I'll be writing up another post after this describing some issues we ran into, in particular with the state of exportables in modules.