Site Definitions, Features, and Solutions in Sharepoint Services 3.0
Developers who have used Windows Sharepoint Services 2.0 as a platform to build business solutions have
found that working with low-level site definitions provides the greatest amount
of control and reusability. A site definition is a directory on the front-end
Web server containing XML files and .aspx page templates that define a
blueprint for the site, including list schemas and page layouts. The XML-based
language that is used inside many site definition files is called Collaborative
Application Markup Language (CAML).
However, there are some issues with this strategy in version 2. First, the XML
files inside version 2 site definitions were poorly factored, making them
unwieldy and hard to work with. Second, there was no support for evolving a
site definition once it had been used to create sites. That means there wasn’t
a supported technique involving site definitions that could be used to add
functionality to an existing Windows Sharepoint Services 2.0 site. Third, site definitions and the
custom assemblies they depend on created deployment issues because the files
had to be pushed out to each front-end Web server in a farm without any
assistance from the Windows Sharepoint Services infrastructure. Finally, Windows Sharepoint Services 2.0 provided no means to
localize a site definition, a somewhat frustrating situation for companies
wanting to internationalize their business solutions.
The first significant Windows Sharepoint Services 3.0 enhancement in this area is the introduction of
features. A feature is like a site definition: a directory containing
CAML-based XML files and page templates. But features offer a much more modular
approach because you don’t need to define the entire blueprint for a site.
Instead, a simple feature can define a single site element such as a custom
list definition or menu commands to be displayed in one of the standard Windows Sharepoint Services
Happily, features can be activated on an existing site. For example, you can
create a feature that defines a custom list type, an instance of that list
type, and an event handler or workflow on that list instance. Once the feature
has been installed, it can be activated in any site within a farm and you can
activate it through the Windows Sharepoint Services user interface, from the command line, or through
custom code written against the Windows Sharepoint Services object model. Once the feature has been
activated, the site will include your new custom list and any behavior you want
to attach to it.
Features also make developing site definitions simpler. In Windows Sharepoint Services 2.0, each list
definition had to be specified inside the context of a site definition. In
version 3 every list definition can be factored out into its own feature. Site
definitions are now easier to create as they can be composed using feature
references. This is the approach taken with all the list types that ship as
part of Windows Sharepoint Services collaboration services.
Windows Sharepoint Services 3.0 introduces a new deployment mechanism called a solution that is similar
to Web Part packages in the sense that it is an aggregate .cab file containing
XML instructions and files that need to be deployed on each front-end Web
server. However, solutions go beyond Web Part packages to support the
deployment of features, site definitions, and related assemblies used for event
handlers and workflows.
Windows Sharepoint Services 3.0 support for solutions also assists in pushing deployment files to each
Web server in a farm. An administrator adds a solution to a Windows Sharepoint Services farm, which
copies the solution .cab file into the configuration database. Next, the
administrator runs a command to deploy the solution, at which time Windows Sharepoint Services starts a
timer job to push the solution .cab file out to each Web server and install it.
A very welcome change for Windows Sharepoint Services developers is the new support for localization.
This functionality has been built on top of the localization infrastructure of
ASP.NET 2.0, and it’s now possible (and recommended) to create site definitions
and features in a language-neutral fashion and to maintain string literals in
.resx files. Within the XML files and .aspx page template files of a feature or
site definition you can acquire the value for a named string that has been
localized into a .resx file using standard ASP.NET syntax.