What's New with Event Handlers

Article
05/05/2014

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Many developers use the event handlers in Windows SharePoint Services to execute custom managed code behind document libraries or form libraries. The goal of Windows SharePoint Services 3.0 is to provide developers with an even richer platform for developing custom integration points and building new types of applications on top of the infrastructure. For this purpose, the event handlers in Windows SharePoint Services 3.0 are extended in scope and depth in many ways.

Event Handler Changes

The most important new extensions to the event handlers include the following:

Greater Event Scope

The scope of events is enlarged and now covers not only document and form libraries but also lists and some limited Web site and site collection events.

Events that are triggered by lists allow you to hook up code when list items are added, changed, or removed, which means you can create customized behavior through Microsoft .NET managed code.

Note

For documents, Before and After properties are guaranteed for post events, such as ItemUpdated, but Before properties are not available for post events on list items.
Events that occur when a user adds or removes fields to a list.
Events that occur when a Web site or site collection is deleted.

Note

Windows SharePoint Services supports provisioning Web site deletion events through the object model, but not through custom Features.

Increased Depth and Richness of Events

The depth and the richness of the events is also a major new enhancement, and there are now two major types of events:

Before events – Events that fire before an action occurs allow you to perform custom validation, checking, or processing of data that is about to be deleted, modified, or added to a list. These types of events are consistently suffixed with 'ing' to identify them as Before events. Note that the code reacting on these events is executed in a synchronous manner.
After events – Events that fire after a certain action occurs probably are familiar to most developers working with Windows SharePoint Services 2.0. These events are suffixed with 'ed' and the code handling them is executed asynchronously.

Greater Event Handler Flexibility

Event handlers are registered differently than in Windows SharePoint Services 2.0, in which it was possible to attach only one assembly per document or form library. In Windows SharePoint Services 3.0, you have more flexibility in handling and registering your events.

Ability to Communicate Responses Back to the User Interface

With Windows SharePoint Services 3.0, you can communicate responses back to the user interface. Take, for example, a scenario in which a user tries to add a new item, and an event handler invalidates that entry because of some business rule. In this case, you can create an error message that is communicated back to the user.

Web Site Creation or Deletion Events

You can create an event handler for the WebDeleting or WebDeleted event so that when a Web site is deleted, it is first backed up and stored in an archive for easy recovery. For the backup mechanism, use the Backup method if the root Web site is deleted; otherwise, use the SPExport class.

To register a callback that fires every time a new Web site is created within a site collection, or globally within a deployment, you can create a Feature for which activation callouts occur when the Feature is activated. Because Features can be scoped to a Web site, creating a Feature that is activated each time a Web site is created provides a Web site creation event. For information about how to associate a Feature with site definitions of a particular type, see Feature/Site Template Association.

Share via