The Filling is the Best Part

In the previous post I showed how to create a list template. In this post we will create an instance of the list and populate it with actual data. This is the real power of a feature for lists. You create the basic Feature.xml and tell it where to look for the Elements.xml file.

In the Elements.xml file you create the following code:


<ListInstance
FeatureId="00BFEA71-DE22-43B2-A848-C05709900100"
Id="1999"
Description="Custom list for the LFI design groups."
TemplateType="100"
Title="LFI Design Groups"
Url="Lists/LFIDesignGroups">
<data>
<rows>
<row>
<field name="Title">35: Chill®</field>
</row>
<row>
<field name="Title">35: Mingle®</field>
</row>
</rows>
</data>
</listinstance>

In the listinstance node you place the feature ID GUID for the feature to base your list instance off of. In the sample code above this is the GUID for the feature of the basic list template. If you do not place a GUID in here, the documentation says that Sharepoint will substitute it with a default one. Don't ever do this as it can screw up the base list templates for the entire server. Always place a GUID in there yourself.

The documentation says that ID is optional but I always include it. It can be pretty much anything, an integer, a string, a GUID. As far as I can tell it is not used by Sharepoint. The only restriction is that it must be unique within the feature.

The description is what you want to show up for the list description. The template type is also grabbed from the list template that you are basing your list on. In this case the list template of 100 is for a custom list.

The title is the title you want to give the list.

The URL is what you want the URL of the list to be.

Inside the listinstance is a data node that contains a rows node and then a row node for each row in the list. Within a row node you place a field node and specify the name of the column that you are going to fill. In this case it is Title. You then place the data inside the node. In this case we are inserting two rows with data of 35: Chill and 35: Mingle. You can place as many nodes as you need to fill your list.

This feature works best if you need to fill a list with static data. You can easily recreate the list later or move the list to a new server such as staging or production.

For more information on list instances:

http://msdn2.microsoft.com/en-us/library/ms476062.aspx

And for more options for a field element:

http://msdn2.microsoft.com/en-us/library/ms437580.aspx

A List Template of Your Very Own

To create your own list template using a feature is pretty easy. The only difficult part is trying to understand the documentation on the MSDN about which attributes are required and which are optional. When it comes to my experience with features and list templates, I have found that all of the attributes should be required, otherwise Sharepoint will place something in there for you and in our case this destroyed the out of the box templates on our Sharepoint site.

The first step is to create the Feature.xml file with a name for your feature and the location of the Elements.xml file.

<feature title="Simple List Feature" id="GUID" scope="Web" xmlns="http://schemas.microsoft.com/sharepoint/">
<elementmanifests>
<elementmanifest location="Elements.xml">
</elementmanifests>
</feature>

After that you can create the Elements.xml file and place the ListTemplate node in there.

<elements>
<listtemplate name="SimpleList" displayname="Simple List" type="20" description="This is my simple list." basetype="0" onquicklaunch="FALSE" securitybits="11">
</elements>

The ListTemplate tag is pretty simple. You give it a name and a display name. The display name shows up in the site settings area for list templates. The description field is used to provide more information about your list template. The basetype is the default schema for the lists created from this template. Most times this will be 0. The onquicklaunch allows the list template to show up on the quick launch bar. The security bits allows for read, write, and schema design security.

There are many other fields that you can use in the list template to customize it the way you want. The resource below lists all of these fields.

<edit>
It has been brought to my attention that I forgot to mention the schema.xml file. At the time that this post was originally written, we copied a schema.xml file from an existing list and then modified it. Microsoft recommends this approach as building the schema file from hand is time consuming and very prone to errors. There are also tools out there that will generate schema files from a list that you build using the UI.
</edit>

http://msdn2.microsoft.com/en-us/library/ms462947.aspx

Back to the Features - Element.xml

In this installment of features we will look at the Element.xml file (or whatever you called it). This is the file that does the actual work in a feature. An example file might look like this:

<?xml version="1.0" encoding="utf-8" ?>
<elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Name="ViewPhotoPage"
Path="Pages"
Url="Pages"
RootWebOnly="FALSE">
<File Url="viewphoto.aspx"
Type="GhostableInLibrary">
<property name="Title" value="View Photo">
<property name="Description" value="The view photo page.">
</file>
</module>
<Module Name="Images"
Url="PublishingImages"
Path="images"
RootWebOnly="TRUE">
<file url="LFILogo_NoByline.gif" type="GhostableInLibrary">
</module>
</elements></p>

The elements element is required to be in the page. Inside this node you place the module nodes. Each module node does one type of similar action. Modules are used for placing files in the appropriate folders. In this feature we have a module called "ViewPhoto". This module places an aspx file in a directory on the Sharepoint site. The path is the location of the file or files in relation to the Elements.xml file. In this case the files are located in a folder called Pages. The URL attribute tells the feature where in the Sharepoint structure to put the files in this module. In this case it is the top level Pages list. The RootWebOnly attribute says if the files can only be accessed in the root web for the site.

Within the module node you place file nodes that specify the actual file. The URL attribute is the URL you want in the Sharepoint structure for this file. Typ determines if the file shows up in the page libraries. If you use GhostableInLibrary, the page will show up when you browse to the pages library.

Within the file node you can place property nodes that give additional attibutes for the file. In this case we have a title property and a description property. This allows for more descriptive information about the files.

Some things to look out for are the naming conventions in Sharepoint 2007. In some areas a library will be called PublishingImages but can be referenced using just Images. When creating features if you get some of the parts wrong, you can mess up the file system and the default templates for a Sharepoint site. Trust me on this one, I will explain some of the mistakes we have made and the issues we have found in later posts.

For now here are some more reference sites that explain more of the options for the Elements.xml file:

http://msdn2.microsoft.com/en-us/library/ms453137.aspx

http://msdn2.microsoft.com/en-us/library/ms434127.aspx

In the next few posts I will demonstrate how to do various activities using features.