Second Life of a Hungarian SharePoint Geek

December 3, 2009

Custom field types as an alternative way for list item event handling in SharePoint

Filed under: Custom fields, SharePoint — Tags: , — Peter Holpar @ 01:33

The availability of custom columns is one of the coolest features in SharePoint. And I think it is the most underutilized one either. The samples found on the web are mostly limited to creating editors for simple data types with custom validation logic like phone numbers or general regular expression validation, or composite (multicolmn) fields, like address field type, having field columns for state, city, street, street number.

Not much words are said about that since custom field controls are part of the form rendering and list item saving process they provide an alternative for handling events in SharePoint.

Let’s see the advantages and drawbacks of custom field types compared to the traditional event receiver based approach.

Pros:

· Custom fields are easy to parameterize per list on the admin user interface through the custom field properties (despite the issues with these properties) when creating the field for the list or for the web, or from code using the same custom properties. Event receivers can be parameterized only through laborious config files or config database tables, or the SPEventReceiverDefinition.Data property that has its limitation of length as 255 characters.

· You can handle events that are not possible to handle with event receivers, like form initialization where you can set defaults for other fields based on your custom logic, or form post back caused by other field, where you can modify the content of other field control (for example, cascading lookups) or even hide / show other fields based on actual field control content.

· You can also handle „item displayed” type events, also not possible using event receivers.

· You can handle field addition / removal events where you can manipulate other fields, like setting defaults, adding extra fields, or you can made other customization as well, like register an event receiver to the list.

· You can interact with the user interface, not trivial in case of an event receiver, so it is easier to create more user friendly validation.

· You can attach multiple instances of the same custom field type for the same list, and you can set individual parameter values for each. That is a great way for interoperation between the instances.

Cons:

· You cannot handle after (-ed) events with custom fields. That kind of events happen after the forms are posted back, so the field controls are out of scope.

· It requires some tricks to access values of other fields, but after you learn the basics it is not much worse than BeforeProperties and AfterProperties.

· By default custom fields has a user interface that may be a drawback when you don’t need that. Of course, you can handle this issue as well, but it requires a few extra lines of code.

· The most important drawback is that custom field controls can help only when the item is displayed / edited on the standard user interface. If the item is edited using web service, custom ASP.NET controls or in the datasheet view they are rather useless.

In the forthcoming posts I’ll try to provide to share my experience with custom fields to illustrate some exciting usage examples of custom fields.

About these ads

3 Comments »

  1. You can also do this kind of work with RenderingTemplates.

    Comment by Brian bedard — December 3, 2009 @ 05:05

  2. [...] item save event using custom fields By pholpar 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 [...]

    Pingback by How to override the default item save event using custom fields « Second Life of a Hungarian SharePoint Geek — December 9, 2009 @ 01:26

  3. [...] with other fields on the form or do something that is not typical to do with custom columns (see my earlier post in this topic) one of the first problems you will face how to hide your field so that it will be [...]

    Pingback by Injecting an invisible custom field to a form « Second Life of a Hungarian SharePoint Geek — December 20, 2009 @ 05:44


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Shocking Blue Green Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 50 other followers

%d bloggers like this: