cat kit | specificity
When you read through Kit, one of the themes that keeps cropping up is the concept of specific relevance. How do you know when it is a good idea to include a given variable, permission, or other component in your Feature?
The answer boils down to this: Keep your Feature lean and mean. Include only what’s necessary for a good, mission-complete piece of functionality. The primary reason for this rule strikes me as the worthy goal of avoiding a horde of bloated, conflicting Features that will make an ill-configured wreckage of the sites that try to use them.
Behind the fold for further thoughts about what specificity means in a well-built Feature.
In thinking about it further (and the way I’ve used Features so far), I found a couple examples of why specificity is worth thinking about.
1. The Over-Configured Content Type
I created a Feature around a new content type. The Feature itself related to how that content was listed around the site (a couple of Views). I exported every variable related to how I had configured the content type, even though my Vertical Tabs settings had no specific relevance to the functionality I was seeking to isolate and export.
For an internal-use sort of Feature, I’m sure this does not matter. (Unless you are trying to define all your Vertical Tabs settings in a different Feature). For a publicly-shared feature, you have now introduced a piece of Vertical Tabs configuration which really has no bearing on the reason someone else might have been interested in your Feature.
2. It’s How I Use It
People disagree on how specialized any given modular website nugget should be. Just look at all the Drupal Modules with overly-themed defaults. Kit specificity in a Feature means the Feature includes only the aspects of theming and site integration necessary for the Feature to make sense, not that your specific use case for that Feature is realized in a shiny exported module.
For internal-use… go for it! Kit is clearly intended as a standard for the growing world of shared Features. Exportables purely for deployment facilitation need not apply. Of course, Kit-compliance from the get-go will surely help you make the unlooked for transition to a publicly published Feature much easier.
1 comment
Let's always separate "mission critical" from "custom"
> Keep your Feature lean and mean. Include only what’s necessary for a good, mission-complete piece of functionality.
An awesome point and a great clarification for those wrapping their heads around making reusable Feature modules.
> For internal-use… go for it!
I challenge us all to always “Include only what’s necessary for a good, mission-complete piece of functionality” and in doing so keep custom configuration in a separate custom Feature modules. I think this results in not only a greater chance you’ll be able to share that Feature module with the wider community, but also results in cleaner and more flexible results. Especially when working on a team, if you are stepping in and have to work on another team mate’s Feature module, it will be a lot more apparent what the intent of the functionality is and where the customization for the client’s use case is when Feature modules are separated into “Mission critical” and “Custom”. This will also help when your client wants to take a radically different direction but still wants the functionality you’ve delivered.