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.
· 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.
· 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.