Two small SPListItem extension methods

So, it is about two small extension methods which do basically the same job – getting a specific field value from a SPListItem instance. Since LINQ to SharePoint is still not quite popular (let’s see if SharePoint 2010 will change that) the SPListItem indexer is the usual way to get the data from a SharePoint list item. It does the job but its main disadvantage is that it operates with objects which means no type safety, cumbersome code, type casts, additional checks, etc.

These two extension methods are generics methods as well – so in the generics parameter you basically specify the return type of the method. And why two – it’s simple – because of the big dichotomy in .NET types – reference and value types. The first method works with reference field value types, the second one with value types (check out the where clause in the methods’ declarations). And the latter’s return type is not actually the generics parameter type but its Nullable counterpart – the SPListItem’s indexer is always expected to return null-s, isn’t it?

    1     public static class ListItemHelper

    2     {

    3         public static T GetValue<T>(this SPListItem item, string fieldName) where T : class

    4         {

    5             object o = item[fieldName];

    6             if (o == null || !(o is T)) return null;

    7             return (T)o;

    8         }

    9 

   10         public static Nullable<T> GetValue2<T>(this SPListItem item, string fieldName) where T : struct

   11         {

   12             object o = item[fieldName];

   13             if (o == null || !(o is T)) return null;

   14             return (Nullable<T>)(T)o;

   15         }

   16     }

And here’s a small sample of how to use the methods:

    1     SPListItem it = list.Items[0];

    2     string title = it.GetValue<string>("Title");

    3     DateTime? created = it.GetValue2<DateTime>("Created");

Overloads of the methods which expect the GUID SPField ID-s can also be created.

How to display all versions in a SharePoint list view page

This is a small article about several undocumented query parameters that can be used on SharePoint list view pages to extract and display additional list data, e.g. the previous versions of the displayed list items.
The parameter that forces the display of all versions of the list items is “IncludeVersions”, it can be used like this:

http://someserver/sites/1/docs/Forms/AllItems.aspx?IncludeVersions=TRUE

A big note here – when you click the context menu commands for the list items they will be applied on the latest version of the item, and for document libraries always the latest version of the document will be opened. So the net value here is only the possibility to see the differences between the values of the displayed fields in the different item versions.
[UPDATE: check this posting for a possible work-around]
Another parameter is the “RootFolder” one, especially when the value that is provided for it is the asterisk character – then it forces a flat view of the list items, analogous to the “RecursiveAll” view scope option:

http://someserver/sites/1/docs/Forms/AllItems.aspx?IncludeVersions=TRUE&RootFolder=*

And here is how using the “IncludeVersions” parameter in conjunction with the well known “FilterFieldN” and “FilerValueN” parameters you can display all latest approved versions of your list (as if you are a user with reader rights who can’t see the pending or draft versions, but sees the latest approved versions of the items that are now pending):

http://someserver/sites/1/docs/Forms/AllItems.aspx?IncludeVersions=TRUE&RootFolder=*&FilterField1=_ModerationStatus&FilterValue1=0&FilterField2=_IsCurrentVersion&FilterValue2=1

Note the fields used to filter all versions – the _ModerationStatus and _IsCurrentVersion, the value 0 for the moderation status field corresponds to the approval status “Approved”.