Lists and document libraries

Lists and document libraries are one of the most important concepts when talking about SharePoint. Most of the work associated with both setting up SharePoint applications and using them in business environment, consist of defining list schemas, creating list instances and operating on list items. Basically, lists and document libraries are actual storages for data. User, by creating choosing content type, and fills particular columns with necessary data, is creating new item on the list. Similarly, by uploading document and describing its metadata, user is creating new item in document library. Lists instances are SharePoint equivalents of database tables [

5

].

WSS is shipped with several built-in list types, which provides a basic functionality sufficient in many business scenarios [28]. Those types include document library, which used to store documents, and supports versioning, workflow, and checking documents out (blocking in order to make some changes) or in (returning them into library). Similar to document library type of list is called form library – it is used to store XML documents and forms, which can be used with Microsoft Office InfoPath. Calendar list is used for tracking events and deadlines, and can integrated with calendar in Microsoft Office Outlook, task list is used to store activity-based items (such as workflow tasks), and project tasks is task list enhanced with Gantt chart view and integration with Microsoft Office Project. Those types, along with several unmentioned in this work, can be basis for creating custom lists definition, which are more adapted to specific business needs. List types and definitions are only templates for actual lists, also known as list instances. There may be several list instances built from the same list definition, so list definition is another way of reusing data structures. Thanks to that, information, which has the same schema (information about employee), can be partitioned among many entities (list of IT department employees, list of management department employees – all based on the same list definition - list of employees).

One of the most important properties of the list is the fact, that there can be multiple content types associated with one list. This enables storing heterogeneous data in one place, which makes SharePoint data storage model even more flexible. For example, there could be a common document library, which supports multiple content types, where all documents that arrived in company are stored temporarily, until business worker move them to specific document libraries, where documents of only one type can be stored.

List definition is considered to be most complex XML-based definition in SharePoint, because of its length – usually several thousand lines [

28

]. The size of the list definition is determined by the fact that it contains many sections such as content type references, local definition of all columns that are incorporated into list, forms and most of all – views, which contains CAML rendering instructions. Additionally, there is also increased complexity in physical structure of the list definition. When list

43 / 116 is to be deployed via feature, the manifest of the feature should, as usual, contain reference to the file with elements of that feature. In this file (Listing 5), list template element should be specified, along with its attributes such as Name and DisplayName, Type and BaseType, attributes which specifies whether list supports versioning and attachments etc.

Name of the list is crucial attribute, because it determines name of the directory within feature directory, which contains schema.xml – file, which contains definition for list schema (Listing 6). This definition enables overwriting some of the attributes specified in list template, as well as defining list metadata, which is most important part of the list, because it contains, as mentioned before, references to content types, fields, views and forms.

The next and final step in defining list is via XML files is instantiating the list. This step is not necessary, because having properly installed list template, it is possible to create list instance from this template via user interface. Nevertheless, there are cases, when business scenario requires hiding list template (Hidden=”TRUE”) and creating only one instance of it. In that case, instance can be defined in CAML (Listing 7) and deployed via feature activation. TemplateType attribute of ListInstance

<List Title="Employees" Url="Lists/Employees" BaseType="0" DisableAttachments="TRUE" VersioningEnabled="TRUE" EnableContentTypes="TRUE" FolderCreation="TRUE" xmlns="http://schemas.microsoft.com/sharepoint/" > <MetaData>

<ContentTypes> <!-- Section for content types --> </ContentTypes>

<Fields> <!-- Section for fields --> </Fields> <Views> <!-- Section for views --> </Views> <Forms> <!-- Section for forms --> </Forms> </MetaData> </List> <ListTemplate Name="EmplyeesList" Type="10001" BaseType="0" DisableAttachments="FALSE" VersioningEnabled="TRUE" Hidden="FALSE" Sequence="2000" DisplayName="Emplyees"

Description="Create a custom employees list."

Image="/_layouts/images/itcontct.gif"

OnQuickLaunch="FALSE"

/>

Listing 5. Example of XML definition of list template

44 / 116 element corresponds with the Type attribute of ListTemplate, and it is an indicator of the template on which instance is based. Again, some of the list template properties can be overridden (OnQuickLaunch), but those changes will apply only to one particular instance. List instances are also useful, because they enable populating lists with data, which is very useful for testing. Within Data node, multiple Row elements can be specified, where each of them represents item on the list, and is defined assigning values to each of its columns, which are identified by their names. The ContentType field is an internal WSS field, which is necessary for identifying the content type for particular item.

In document Modelling of Enterprise Portals with Domain- Specific Language (Page 42-44)