sábado, 28 de enero de 2012

Sharepoint 2010 Item Event Receiver

image

Item Event Receivers derive from the SPItemEventReceiver class and have a number of methods that can be overridden to respond to various events:

As you look through this list, you should notice that events have two types of endings:

  1. Events ending in ING:
    • Examples include ItemAdding, ItemDeleting, ItemUpdating, etc.
    • These events occur BEFORE the action takes place. This means that you have a chance to modify the item or cancel the operation before it occurs.
    • These event handlers run synchronously – they occur in order and one must complete before the next is run.
    • You may be able to modify property values in the event handler.
      • Each event method has a SPItemEventProperties parameter named properties. If you wish to modify a property value on the list item during the event, the value should be updated in AfterProperties property of the properties parameter. SharePoint reads these values from the event parameter and modifies the item accordingly when the actual operation runs (e.g. the actual Add / Update operation for which the Adding / Updating event is being fired). Do NOT try to manually get the list item in code and update a property on it because the optimistic locking mechanism in SharePoint may throw an error later on when the operation associated with the event to which you are responding attempts to complete.
  2. Events ending in ED:
    • Examples include ItemAdded, ItemDeleted, ItemUpdated, etc.
    • These events occur AFTER the action takes place. This means that you can respond to the event but you cannot cancel it or modify anything about it.
    • These events handlers may run synchronously or asynchronously depending on how they are configured. Asynchronous operations may occur in any order and complete in order.
    • Property modification is not available in an asynchronous event handler (even if it is running synchronously).
      1. Although asynchronous events expose a SPItemEventProperties parameter named properties just like their synchronous counterparts, remember that the operation has already completed so you cannot modify anything in the properties parameter (well, you can, but it doesn’t do anything). Additionally, the properties parameter may not be populated with information that you would tend to expect to be present.

Fuente:

http://www.simple-talk.com/dotnet/

 

Más información:

http://www.sharepointbriefing.com/spcode/article.php/3872616/Using-the-Event-Handler-in-SharePoint-2010.htm

http://sharepointx-men.com/2010/07/09/sharepoint-2010-event-receivers-part-1-create-event-receiver-for-content-types/

Cambiar el título de un item al agregarse: http://www.learningsharepoint.com/2010/06/27/creating-event-receiver-in-sharepoint-2010/

List Event Receiver se dispara dos veces: http://auislam.wordpress.com/2011/08/08/item-added-event-receiver-firing-twice/ ; http://www.simple-talk.com/dotnet/.net-tools/managing-itemupdating-and-itemupdated-events-firing-twice-in-a-sharepoint-item-event-receiver/

Custom error pages: http://www.zimmergren.net/technical/sp-2010-how-to-event-receivers-and-custom-error-pages

http://msdn.microsoft.com/en-us/library/ff648923.aspx

http://msdn.microsoft.com/en-us/library/ie/ff728093.aspx

No hay comentarios:

Publicar un comentario