When a Feature Isn't the Same Thing as a feature
Hopefully it isn't any sort of a great revelation to anyone that the latest versions of SharePoint (WSS v3 and MOSS 2007) have a lot of great new features, such as blogs, wikis, Excel Services, and many more. I also hope that almost a year after their release, that you've gotten a chance to experience and use some of these new features. But there is one item in the update feature sets for SharePoint that may be a cause for some confusion: Features.
Huh? What kind of recursive nightmare am I trying to perpetuate? Features are a feature? That doesn't make any sense, does it?
Well, in SharePoint it does. One of the new features in the latest version of SharePoint is a piece of functionality titled "Features." Please don't hate me for this confusing wordplay; I didn't come up with it. And I would go so far as to encourage you not to hate on the SharePoint product team for this either; I've wracked my brain to try and come up with an alternative name for this and failed. I'm not here to criticize (this time
), I'm here to edjamakate you.
Once you get beyond the name, Features are great. Out of the box they provide an easy way for site admins and farm admins to turn on and off different components of a SharePoint site. Depending on your version of SharePoint, you'll find stock Features that determine what web parts or workflows are available for use within a site. You don't have to install any applications or run an administrative process on a server to make these components available; you just have to enable the Feature you want to use.
<cue Ron Popiel>But wait! There's more! </Ron>
While the Features included with SharePoint are pretty nice, the best feature of Features (sorry, I'm in a weird mood today) is how useful they can be to developers. You can develop your own Feature and deploy them in your SharePoint environment so that they can be used within sites, allowing you to attach your own web parts, workflows, lists, etc. to your site collections for optional deployment. Additionally, you can require that a Feature be deployed to a site, if you want to enforce it usage at all times.
Use of a technique called Feature Stapling allows you to add new functionality to a site definition (the underlying template physical files SharePoint uses to create a site) without actually modifying the site definition itself. Feature Stapling occurs when you create Feature containing your new functionality, and then create a second Feature responsible for applying (or stapling) the first Feature to a site definition. It's a little complicated, but trust me, it's definitely developer- and administrator-friendly.
So to review: in the world of SharePoint the word "feature" has two different meanings. When using a lowercase "f", the term refers to the vast array of functionality offered by the platform. When using a capital "F", it is referring to a specific component of SharePoint that can be used to selectively enable and disable functionality within sites.
For more information, check out the following links:
Posted on SharePoint Blogs
Del.icio.us |
Digg It |
Technorati |
Blinklist |
Furl |
reddit |
DotNetKicks
Read the complete post at http://www.sharepointblogs.com/fortheuser/archive/2007/11/15/when-a-feature-isn-t-the-same-thing-as-a-feature.aspx