And here's the actual SPList implementation
So let’s pick it off from where we’ve left the last time. We’ve defined some base classes we’re going to use throughout our solution:
- BaseList – abstract base class
- An abstract configuration
- A concrete implementation of the configuration
- And a configuration factory, which was taking care of the initialization process of the instance of the configuration class.
Today, we’ll add something more practical to the solution. We’ll define a concrete instance of the SPList (by inheriting from it and adding some additional methods).
So the purpose is to be able to work with custom list – one that is a part of either a WSS or a Sharepoint site.The list might have to be exposed for use in an external application – like let’s say a smart client application, though a web service. But how do we do that? Do we have to define references to the Microsoft.Sharepoint assembly at the client side in order to do that? Well, we better don’t ‘couse that doesn’t sound like a good design decision, does it :).
So how can we expose a list through a web service for usage from outside clients like smart client applications or even from apps based on platforms other than MS .NET? We’ll define a bunch of data container classes that will have the ability to serialize and de-serialize (with the use of [SerializableAtttribute] class from .NET). What that actually means, is that we’ll have to define the schema of the messages (our serializable classes will be a part of the schema) and then define a custom logic for converting the list items to those custom types.
So we need the following:
- a list inheriting from the base class
- a [ListItem] class (supporting serialization)
- a custom logic for converting from SPListItem to the custom [ListItem] class instances.
So let’s say that we have a very simple list that has only two fields we’re interested in – a “Title” and a Guid.
The list definition should look like this:
We’ve mentioned that we’re interested in 2 fields, not one. The fact is that every list contains a bunch of fields that are hidden from the user. One of them is called "GUID" and is of type Guid, which maps to the System.Guid in the .NET Framework. The other field, we can also use as an identifier is the ID field of type int.
So as you see, we have two different Find methods, and one Convert method. The two different Finds will be used when we want the ability to get an instance of the SPListItem, when we know either the Giud or the integer ID of the item. Internally WSS and SPS use auto-increment for the most of the identities, so there’s a pretty good chance we’ll need both Guid and the integer ID.