One of the major concepts in WSS3.0 is the "Feature". The Feature is a container of various defined extensions for SharePoint. It’s a set of XML files which are deployed to web front ends, that can be bundled in site definitions or individually turned on in SharePoint sites. In the next few blog posts, I’ll try to cover some of the more esoteric capabilities of Features, but before I do that, it’s probably helpful to define a Feature, first.
The typical scenario is if you want to deliver a new "Ratings" capability for SharePoint. You want to make it easy for someone to tag any particular item with a rating, and then aggregate those ratings and provide statistics on them. To implement Ratings, you’d need to develop a custom list for storing ratings, and web parts for displaying those ratings. To make this happen in SharePoint, you’d deliver that as a Feature. The Feature would contain a list definition for defining how Ratings are stored, a list instance for defining the common store of Ratings, a web part definition for showing highly rated items, and perhaps a dashboard web page for aggregating different types of rating views together. From the end users perspective, they could "activate" (turn on) your Ratings Feature in their site, and the Ratings list and web parts would be made available to them. (yes, ok, this is just a mythical sample. I'll try to come up with code to illustrate this in a future post.) The key point is that the Feature in SharePoint is a way to bundle all of these extensions together and get them provisioned into a SharePoint site.
Features have a scope, and can be associated with various scopes in SharePoint: web, site, web application, or farm. Depending on the scope, different types of individual elements can be defined in XML. For example, you can associate a List Instance at the Web Scope (every provisioned web will get a list provisioned along with it), but you can’t associate a List Instance at the Farm scope.
Site- or web-scoped Features can also be referenced within a site definition, so that as new sites get created your features will get activated.
Ultimately, though, not every behavior or kind of change you’d want to implement can be expressed in XML. For this reason, you can also define a feature receiver which contains callbacks which will get fired when the Feature is installed or activated.
Features are designed to be a way for developers to express building blocks for SharePoint, and for site admins to pick and choose new functionality they can add to their site. Out of the box, Microsoft Office SharePoint Server and WSS have about 128 features defined, combined. That’s a lot of building blocks :)
Ok, but why is it called a 'Feature"? It’s kind of a bit awkward to talk about the "Feature feature".
Yep, the name "Feature" leads to some occasional contortions when you talk about it.
Why call it a feature? There were a couple of reasons. First, one goal was to make it possible for people to choose a site template, but over time add (or remove) capabilities as people needed them -- the philosophy is that choice of site template shouldn’t be a binding choice to force particular functionality for a site forever. To implement this, we needed to express to site admins which set of capabilities they can turn on. Calling these capabilities "Features" seemed to be more intuitive than calling them something a bit geekier, like "modules" or "components". Because the UI term for these was "Features", it made sense to call the development capability called "Features" too.
Second, the design of features was in part influenced by the way things are defined in Windows Installer. Windows Installer has the concept of "features" and "components". Features are those things you see in some setups where you can pick and choose, in a tree view, which various bits of software to install. For a brief moment the idea for SharePoint was to have features and components too, but to simplify things a little bit we just put features in (not components.)
Well, those are the reasons for the "Feature" name in any case :). The main hope is that with the Features capability we’ve made it easier for developers to create more compartmentalized, reusable bits of functionality for SharePoint.