How to override the default item save event using custom fields

 

In my former post I wrote about the approach to use custom field types as an alternative way for list item event handling in SharePoint. In the current post I would like to show you how to inject code into the edit item or new item forms using a custom field that intercepts the default item save event.

You can put the event handling in a custom field that has some other role on the user interface, or it can be a custom field without its own UI that serves only the special role of event handling. I will show you an example for the latter one in a later post.

You might ask why is it useful to be able to do that. Let’s see some examples for the usage.

Do actions before saving the item, like:

· Cross-field or even cross-list validation of the item, for example, the start date of the event must be less than the end date, or the value of the Affected tasks field for an item must be less than the count of the task items in another list.

· Extra permission checks, for example, based on the item fields, like only the creator of the item can modify the status.

· Add validation errors to the affected fields and cancel the save, if the above validations fail.

· Update field values on the fly for the same item or even an item in another list, like call a web service using the login name of the modifier and store the results in one of the fields.

Do actions after saving the item, like:

· Notify back-end systems about the change, for example, call a web service, update / insert a record in an SQL server table or create a new SharePoint list / site based on the field values.

· Redirect the user to another page.

· Set permissions on the item, for example, set write permissions using elevated privileges for the users or groups that were specified in a Person or Group field. This may be useful since it enables users with edit permissions to set item security.

There are two similar ways to intercept the base item save process, both of them is provided by the BaseFieldControl class, so you should put the code in the field control class of the custom field.

First approach is to override the UpdateFieldValueInItem method:

1. public override void UpdateFieldValueInItem()
2. {
3.     Page.Validate();
4.     if (Page.IsValid)
5.     {
6.         // do actions before save
7.         // do the save if required
8.         base.UpdateFieldValueInItem();
9.         // do actions after save
10.     }
11.     else
12.     {
13.         // do actions instead of save
14.     }
15. }

 

The another alternative is to attach your own event handler to the OnSaveHandler property of the SPFormContext class:

 

1. protected override void OnInit(EventArgs e)
2. {
3.     base.OnInit(e);
4.     // add save handler only in New and Edit modes
5.     if ((SPContext.Current.FormContext.FormMode == SPControlMode.New) || (SPContext.Current.FormContext.FormMode == SPControlMode.Edit))
6.         SPContext.Current.FormContext.OnSaveHandler += new EventHandler(MyHandler);
7. }
8. protected void MyHandler(object sender, EventArgs e)
9. {
10.     Page.Validate();
11.     if (Page.IsValid)
12.     {
13.         // do actions before save
14.         // do the save if required
15.         SPContext.Current.ListItem.Update();
16.         // or you can save the item using this line of code either
17.         //SaveButton.SaveItem();
18.         // do actions after save
19.     }
20.     else
21.     {
22.         // do actions instead of save
23.     }
24. }

If you don’t call the methods that save the item to the SharePoint list your form can be used as a front-end for a back-end system as well, for example, you can call a web service or insert SQL records without affecting the content of the SharePoint list. But that is probably not the most ergonomic usage of SharePoint and the easiest way to create web based user interface for back-end systems.