I recently declared an Event Receiver through a SharePoint Feature: Event Registrations
Some of the samples online had surprising elements such as <Data /> and <Filter />. I have never seen them used before and didn’t know their purpose. Perhaps they are not to be messed with ? Perhaps great power lies within ?
- Data – Specifies a string that will be passed as a parameter to the receiver method when handling the event
This one is commonly found in the documentation. It can be used to declare additional information and then the Event Receiver code behind can use this information. Better than hardcoding although I haven’t had the need for it (yet ?).
- Filter – Reserved. Filter MUST be NULL
According to the official docs it is reserved: Event Receivers Result Set
Thank you Thomas for helping me on this one !
Also here’s a good reference: SharePoint 2007 Deployment: Event Registration Features
I'm currently doing quite some research on Event Receivers (ERs) on Content Types (CTs) and activating those CTs on a document library in SharePoint 2007 (WSS 3.0 to be exact, but same applies for MOSS 2007 and MSS(X) 2008).
The setup is a single document library with
- the out of the box Document Content Type (no event receivers defined)
- a custom ContentType1 having an EventReceiver1 for any possible event (ItemAdding, ItemUpdating, ItemAdded, …)
- a custom ContentType2 having an EventReceiver2 for any possible event
In the scenario’s situation ‘A’ has Document as default Content Type, while situation ‘B’ has ContentType1 as default.
Some scenarios
1. Create a new document of type ‘Document’ (New button)
A. No events are fired because there are none defined for this Content Type
None
B. (same as A)
2. Create a new document of type ‘ContentType1’ (New button)
A. The Office client application “knows” the Content Type and will save directly as that and fire the defined events
EventReceiver1.ItemAdding, EventReceiver1.ItemAdded
B. (same as A)
3. Create a new document and save it to the document library (starting from Word)
A. The Office client application will ask the Content Type before saving and fire the events defined for that Content Type
None
B. (same as A)
4. Upload a document using the Single File page
A. All ItemAdding events fire. The default CT is assumed. Afterwards the user is presented with the option to change the Content Type which will trigger ItemUpdating and ItemUpdated for the destination Content Type
EventReceiver1.ItemAdding, EventReceiver2.ItemAdding
B. All ItemAdding events fire. The default CT is assumed. Other events defined for that Content Type also trigger
EventReceiver1.ItemAdding, EventReceiver2.ItemAdding, EventReceiver1.ItemAdded
5. Upload a document using the Multiple Files page
A. All ItemAdding events fire. The default CT is assumed
EventReceiver1.ItemAdding, EventReceiver2.ItemAdding
B. All ItemAdding events fire. The default CT is assumed
EventReceiver1.ItemAdding, EventReceiver2.ItemAdding, EventReceiver1.ItemAdded
6. Copy and paste a document of type ‘Document’
A. All ItemAdding events fire. The Content Type of the source file is assumed
EventReceiver1.ItemAdding, EventReceiver2.ItemAdding
B. (same as A)
7. Copy and paste a document of type ‘ContentType1’
A. All ItemAdding events fire. The Content Type of the source file is assumed. Other events defined for that Content Type also trigger (only Update, not Add)
EventReceiver1.ItemAdding, EventReceiver2.ItemAdding, EventReceiver1.ItemUpdating, EventReceiver1.ItemUpdated
B. (same as A)
8. Restore a document of type ‘Document’ from the Recycle Bin
A. All ItemAdding and ItemAdded events fire
EventReceiver1.ItemAdding, EventReceiver2.ItemAdding, EventReceiver1.Added, EventReceiver2.ItemAdded
B. (same as A)
9. Restore a document of type ‘ContentType1’ from the Recycle Bin
A. All ItemAdding and ItemAdded events fire
EventReceiver1.ItemAdding, EventReceiver2.ItemAdding, EventReceiver1.Added, EventReceiver2.ItemAdded
B. (same as A)
10. Restore a previous version of a document of type ‘Document’
A. No events fire
None
B. (same as A)
11. Restore a previous version of a document of type ‘ContentType1’
A. The ItemUpdating and ItemUpdated events defined for the Content Type fire
EventReceiver1.ItemUpdating, EventReceiver1.Updated
B. (same as A)
Lessons learned
- All ItemAdding events trigger in case of file upload via WebDAV or the Upload page
- Copying a file triggers the ItemAdding and ItemUpdating events, but not the ItemAdded event
- Restoring from the Recycle Bin triggers all ItemAdding and ItemAdded events regardless of Content Type
- Restoring a previous version is seen as an update (makes sense)
I’m starting to see the light although I do think that the Recycle Bin thing is a design flaw. Be careful on how you implement Event Receivers. Currently I’m thinking an additional check on Content Type in your code might be the safest way to ensure your code doesn’t run accidentally for a different Content Type ? What do you think ?
Today I got into some code reviewing of an Item Event Receiver using Enterprise Library for data access. The problem occurred when registering the Event Receiver for a SharePoint List using the object model (SPList.EventReceivers.Add)
Exception has been thrown by the target of an invocation.
Here's a simplified view into the code:
public class MyEventReceiver: SPItemEventReceiver
{
MyDataAccess da = new MyDataAccess();
public override void ItemAdded(SPItemEventProperties properties)
{
...
}
}
public class MyDataAccess
{
public MyDataAccess()
{
Microsoft.Practices.EnterpriseLibrary.Data.DatabaseFactory.CreateDatabase("MyDB");
}
...
}
Apparently when the Event Receiver is registered it instantiates the MyDataAccess class which in turn calls the EntLib method in its constructor. This is what causes the exception.
A solution is to instantiate the MyDataAccess class in the methods rather than on event receiver initialisation:
public class MyEventReceiver: SPItemEventReceiver
{
public override void ItemAdded(SPItemEventProperties properties)
{
MyDataAccess da = new MyDataAccess();
...
}
}