Sharepoint 2010 : SharePoint Events (part 2) - SharePoint 2010 Improvements in the Event Model

1. SharePoint 2010 Improvements in the Event Model

SharePoint 2010 significantly enhances the event model of SharePoint. There is a concept of postsynchronous events, so the "ed" events can now be executed synchronously, thereby eliminating any chance of the user seeing uncooked data because the event finishes execution before the end user sees the rendered page. Also there is the ability to show custom error pages in case the event receiver chooses to cancel an event. Custom error pages are not possible in post-synchronous events, however.

Then there are various new events that have been added since SharePoint 2007, there are new registration capabilities allowing you to register events at SPSite or SPSite.RootWeb by defining the scope of an event registration.

Finally, it is common practice to start a workflow based on data changed in an item or the creation of an item. While the item was changed under the user's context, the workflow runs under the system account. This is usually a problem because if the workflow intends to change the item, and in certain situations say where the user had checked out an item to edit the item, the check-in, check-out mechanism of SharePoint may interfere with the updating. This is because technically you have two users (System and end user) trying to edit the same list item. SharePoint 2010 now adds the originating user and user token on SPEventPropertiesBase. Thus things such as workflows can now impersonate back to the originating end user to perform such updates. They are many other such situations in which you will find this facility useful. For instance, code that runs under timer jobs will also find this facility useful.

Let's look at a quick example of writing an event receiver that takes advantage of SharePoint 2010 capabilities. The specific example I intend to show here will enhance the previous Surveyrigger EventReceiver to run synchronously instead. This way, there is no danger of the user ever seeing half-cooked results. Changing an asynchronous event receiver to a post-synchronous EventReceiver is rather simple. You simply edit the element.xml of your EventReceiver, as shown in Listing 3.

Example 3. Post-synchronous EventReceiver element.xml

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/SharePoint/">
 <Receivers ListUrl="/Lists/Sahil%20Feedback/">
   <Receiver>
    <Name>SurveyriggerItemAdded</Name>
    <Type>ItemAdded</Type>
    <Assembly>$SharePoint.Project.AssemblyFullName$</Assembly>
    <Class>EventReceivers.Surveyrigger.Surveyrigger</Class>
    <SequenceNumber>10000</SequenceNumber>
    <Synchronization>Synchronous</Synchronization>
   </Receiver>
 </Receivers>
</Elements>

Specifically the following element under the Receiver element was added:

<Synchronization>Synchronous</Synchronization>

That's basically it: compile, build, and deploy; but before you take the survey again, you will have to do two things:

• Delete your previous response because the survey will not allow the same user to respond to the survey multiple times.

• This time around, run the project in debug mode by hitting F5 in Visual Studio, which will launch the browser and point it to http://sp2010.

Now go ahead and take the survey once more and note that your EventReceiver executes before the page control is handed back to the user. In other words, the event executes synchronously.

Now that the rigged survey is running in production, people have begun to complain again! Basically they're saying that their responses should not be changed by the EventReceiver. I don't know why they are complaining, why can't they accept my Surveyrigger as a feature, not a bug?

Because I am a good consultant, instead of changing the responses from "No" to "Yes", I will instead make a little change to my EventReceiver next. Specifically if the user enters "No" as their choice, I will reject their answer and show them a custom error page. Because by now you are an expert in writing EventReceivers, I'll just give you the high-level steps to achieve this. You should go ahead and try to make this change yourself.

• Custom error pages can be shown by setting SPItemEventProperties.RedirectUrl. SPItemEventProperties is the parameter passed into your event receiver event handler method. However, custom error pages cannot work with "ed" events, synchronous or not. Thus you're going to have to tap the ItemAdding event handler rather than the ItemAdded event handler.

• In the item adding event handler, look for (SPItemEventProperties) properties.AfterProperties to check for the newly added survey response value. If the value is "No", you can cancel the event handler execution by setting properties.Cancel = true. If you have already set the properties.RedirectURL property, at this time a dialog box will pop open in the browser that will inform the user of the error. Provide a suitable error message such as "You nitwit, the right answer is YES!".

• The custom error message, in the RedirectURL, is actually an ASPX. This ASPX can be either a site page or an application page. I would be especially proud of you if you were to implement this as a SitePage and thus your solution remains a sandbox solution.

Go ahead and give this a try yourself. Also play with as many EventReceivers as you wish. Once you're done playing, come back and let's talk about list scalability in SharePoint.