Inconvenient Site Columns

Windows SharePoint Services (WSS) v3 introduces the concept of Site Columns: reusable fields which can be used for creating content definition across the whole Site Collection. While this concept allows you to manage the way content is stored, you have to be really careful when working with Site Columns in custom development.

Yesterday I have introduced a new version of Imtech Fields Explorer which simplifies working with Content Types and Site Columns in custom code by generating wrapper classes. For generating these classes I have used the SPField.InternalName property. While testing wrapper classes generated by Imtech Fields Explorer I have noticed something odd in WSSv3.

There are various scenarios of working with Content Types and Site Columns. Probably the most common are updating a Site Column:

and updating a value of a particular field in a List Item:

In both scenario’s you need to get to the field prior to operating on it. As you have probably noticed you have to pass different values to get to the field depending on the context. If you retrieving an item from the SPFieldCollection (first scenario) you need to pass the Display Name (SPField.Title) in order to obtain the reference to the Site Column you want to update. While working with List Items and field values however you may use either the internal (SPField.InternalName) or the display name. So why is this problematic?

Site Column’s display name doesn’t have to be unique. As you can see on the picture below taken by Imtech Fields Explorer, there can exist multiple Site Column with the same display name.

A problem arises as soon as you try to obtain such Site Column using the display name. If there are multiple Site Columns with the same display name (SPField.Title) the SPFieldCollection will return you the most recently added Site Column.

To avoid that problem you could of course use GUID’s (SPField.Id property) in your custom code. The biggest downside of that approach is poor maintainability and no overview. You would have to keep either the display or the internal names for all GUID’s in order to keep your code readable. To simplify that I will provide an update for the Imtech Fields Explorer which will use GUID’s instead of internal names for generating wrapper classes.

Technorati Tags: SharePoint, SharePoint 2007, WSS 3.0, MOSS 2007