11.SharePoint 2007 Deployment: Content Type Binding Features

As  mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the binding of content types.
You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Content Type Binding

When you provision a list through a feature, using the method explained in the post SharePoint 2007 Deployment: List Template Features, you can bind a content type to it only by editing the schema.xml file of the list template.
However, if the list was provisioned through a site definition (onet.xml file) and you had no access to its definition, you must do it using a Content Type Binding feature element. This can only be used to attach a content type to a list provisioned through a site definition.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with content type binding elements can only be deployed to a Site Collection scope.
Attempting to install a feature of another scope that contains content type binding elements, will result in an error.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
    xmlns="http://schemas.microsoft.com/sharepoint/"
    Id="{ACDECF85-BDF7-446c-AC1B-C5F133C83F15}"
    Title="Content Type Binding"
    Description="This feature binds a content type to the masterpagegallery."
    Scope="Site"
    Creator="Create IT"
    Version="1.0.0.0">
  
  <ElementManifests>
    <ElementManifest Location="ContentTypeBinding.xml"/>
  </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is Content Type Binding.
• It will be deployed as a Site Collection feature, since it's Scope value is Site.
• It references a single element manifest file: ContentTypeBinding.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it's called ContentTypeBinding.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <ContentTypeBinding> element which is used to binding Content Types to list definitions.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentTypeBinding
    ContentTypeId="0x010101"
    ListUrl="_catalogs/masterpage" />
</Elements>

This example binds the content type Form (which has the ID 0x010101) to the master page gallery (which has the URL _catalogs/masterpage). There <ContentTypeBinding> element has no child elements, and only two attributes:

• ContentTypeId - (required) The ID of the content type that will be bound to a list.
• ListUrl – (required) The URL of the list to which the content type will be bound.

Additional Notes

The content type will be bound to the list definition as soon as the administrator activates this feature on a site collection. However, deactivating the feature will not remove the connection between the content type and the list. If you wish to remove it, you must do so manually.

Sample

You can download this sample here. This sample includes:

• The solution manifest file (manifest.xml).
• The solution cab structure file (solution.ddf).
• The feature manifest file (feature.xml).
• The content type binding element manifest file (ContentTypeBinding.xml).
• A batch file (build.bat) that creates the solution package (ContentTypeBinding.wsp).

10.SharePoint 2007 Deployment: Event Registration Features

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the registration of event receivers.
Additionally, you must include the assembly that contains the event receiver class in the solution package, so that it gets deployed to the Global Assembly Cache. Follow the instructions in the post SharePoint 2007 Deployment: Creating Solutions on how to package these three files (both manifests plus the assembly file) on a SharePoint Solution file.

Events Receivers

SharePoint allows you to handle several events that are fired according to actions performed on items, lists and web sites. Event are handled through event receivers, which are classes that implement a method for each event that is handled.
Once an event receiver is developed, compiled into an assembly and deployed to the GAC, it must be registered to a content type, a list or a web site in order to handle its events. That can be done through the API (or third-party tool such as Event Handler Explorer) or, concerning item and list event receivers, through this type of feature.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with event registration elements can only be deployed to Web Site scopes.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
    xmlns="http://schemas.microsoft.com/sharepoint/"
    Id="{282902FB-0369-4f98-93C5-7FD7121CE164}"
    Title="My Event Receiver"
    Description="This feature registers My Event Receiver."
    Scope="Web"
    Creator="Create IT"
    Version="1.0.0.0">
  <ElementManifests>
    <ElementManifest Location="EventReceivers.xml"/>
  </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My Event Receiver.
• It will be deployed as a Web Site feature, since it's Scope value is Web.
• It references a single element manifest file: EventReceivers.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it's called EventReceivers.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <Receivers> element which is used to register event receivers that will handle list events.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Receivers 
    ListTemplateId="3500" 
    ListTemplateOwner="{11663D54-6152-4532-ABF5-FC08FAC216A7}">
    <Receiver>
      <Assembly>
        MyEventReceiver, 
        Version=1.0.0.0, 
        Culture=Neutral, 
        PublicKeyToken=6c0c7604915f786e
      </Assembly>
      <Class>MyEventReceiver.MyEventReceiver</Class>
      <Name>My Event Receiver</Name>
      <Type>ItemAdded</Type>
      <SequenceNumber>10000</SequenceNumber>
    </Receiver>
  </Receivers>
</Elements>

The example above registers an event receiver to all lists based on list template with ID 3500 that was deployed by a feature with the ID {11663D54-6152-4532-ABF5-FC08FAC216A7}. The receiver is the MyEventReceiver.MyEventReceiver class included in the assembly MyEventReceiver.dll that is installed in the GAC, and it handles the ItemAdded event on these lists.
The Receivers Element
The <Receivers> element is used to specify the list template to which the event receiver will be registered. There can be any number of <Receivers> elements in a single element manifest file. Here is a summary of the possible attributes of this element:

• ListTemplateId - (required) Specifies the ID of the list template to which the event receiver will be registered. If you wish to register an event receiver to one of SharePoint’s list templates, you can use one of the following values:
  • 100 – Generic List
  • 101 – Document Library
  • 102 – Survey
  • 103 – Links List
  • 104 – Announcements List
  • 105 – Contacts List
  • 106 – Events List
  • 107 – Tasks List
  • 108 – Discussion Board
  • 109 – Picture Library
  • 110 – Data Sources
  • 111 – Site Template Gallery
  • 112 – User Information List
  • 113 – Web Part Gallery
  • 114 – List Template Gallery
  • 115 – XML Form Library
  • 116 – Master Pages Gallery
  • 117 – No-Code Workflows
  • 118 – Custom Workflow Process
  • 119 – Wiki Page Library
  • 120 – Custom grid for a list
  • 130 – Data Connection Library
  • 140 – Workflow History
  • 150 – Gantt Tasks List
  • 200 – Meeting Workspace Series List
  • 201 – Meeting Workspace Agenda List
  • 202 – Meeting Workspace Attendees List
  • 204 – Meeting Workspace Decisions List
  • 207 – Meeting Workspace Objectives List
  • 210 – Meeting Workspace text box
  • 211 – Meeting Workspace Things To Bring List
  • 212 – Meeting Workspace Pages List
  • 301 – Blog Posts List
  • 302 – Blog Comments List
  • 303 – Blog Categories List
  • 1100 – Issue Tracking
  • 1200 – Administrator Tasks List
• ListTemplateOwner - (optional) Specifies the GUID of the Feature where the list template is defined, or the name of the site definition that registered the list.

The Receiver Element
The <Receiver> element specifies which class implements the event receiver and which list event it handles. There can any number <Receiver> child elements inside a <Receivers> parent element. This element has no attributes, but has six child elements, which are listed below:

• Assembly – The strong name of the assembly that contains the event receiver class. The strong name is composed of the name of the assembly (without the .dll extension), followed by a comma and the assembly version, followed by a comma and the assembly culture, followed by a comma and the assembly’s public key token.
• Class – The name of the class (including the namespace) that contains the implementation of the event receiver.
• Name – The name of the event receiver. This value is used to identify it if you wish to retrieve it through the API.
• Type – The event that the event receiver handles. Possible values are:
  • ContextEvent – The list received a context event.
  • EmailReceived – The list received an e-mail message.
  • FieldAdded – A field was added to the list.
  • FieldAdding – A field is being added to the list.
  • FieldDeleted – A field was removed from the list.
  • FieldDeleting – A field is being removed from the list.
  • FieldUpdated – A field was updated in the list.
  • FieldUpdating – A field is being updated in the list.
  • ItemAdding – An item is being added to the list.
  • ItemAdded – An item was added to the list.
  • ItemAttachmentAdded – An attachment was added to an item.
  • ItemAttachmentAdding – An attachment is being added to an item.
  • ItemAttachmentDeleted – An attachment was removed from an item.
  • ItemAttachmentDeleting – An attachment is being removed from an item.
  • ItemCheckedIn – An item was checked-in in the list.
  • ItemCheckingIn – An item is being checked-in in the list.
  • ItemCheckedOut – An item was checked-out in the list.
  • ItemCheckingOut – An item is being checked-out in the list.
  • ItemDeleted – An item was removed from the list.
  • ItemDeleting – An item is being removed from the list.
  • ItemFileConverted – A file was converted.
  • ItemFileMoved – A file was moved.
  • ItemFileMoving – A file is being moved.
  • ItemUncheckedOut – An item was unchecked-out in the list.
  • ItemUncheckingOut – An item is being unchecked-out in the list.
  • ItemUpdated – An item was updated in the list.
  • ItemUpdating – An item is being updated in the list.
• SequenceNumber – Specifies the order of the event receiver when more than one handler is associated with the same event. A high sequence number (10000 or higher) should be used to prevent problems with SharePoint’s own event handlers.
• Data – Specifies a string that will be passed as a parameter to the receiver method when handling the event.

Sample

You can download this sample here. This sample includes:

• The solution manifest file (manifest.xml).
• The solution cab structure file (solution.ddf).
• The feature manifest file (feature.xml).
• The event receiver element manifest file (EventReceivers.xml).
• A fake assembly (MyEventReceiver.dll) that must be replaced by your own assembly. Important: this file is not a real assembly containing an event receiver class, hence it will not work if deployed as is to your Sharepoint environment.
• A batch file (build.bat) that creates the solution package (MyEventReceiver.wsp).

9.SharePoint 2007 Deployment: Module Features

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the provisioning of files (modules) in a SharePoint site.
You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Modules

Modules are collections of files that must be provisioned in a SharePoint web site. This type of feature element can be used to:

• Add pages to a web site
• Add web parts to a web site's web part gallery
• Add web parts to a web part page
• Add documents to a document library
• Add style sheets to the a web sites style library

According to the documentation, WSS 3.0 supports provisioning a maximum of 1000 files through module feature elements (whether using a single module element with 1000 files, or 1000 module elements each with a single file).

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with module elements can be deployed to Site Collection and Web Site scopes, since they represent files that are to be placed in web sites.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature
  xmlns="http://schemas.microsoft.com/sharepoint/"
  Title="My Module Feature"
  Id="17E94729-EF3E-4f43-9385-88E1201F91E0"
  Description="This feature adds files to the web site."
  Version="1.0.0.0"
  Scope="Web"
  Hidden="FALSE"
  DefaultResourceFile="core">
    <ElementManifests>
        <ElementManifest Location="Modules.xml" />
        <ElementFile Location="default.aspx" />
        <ElementFile Location="MyMasterPage.master" />
        <ElementFile Location="MyDocument.docx" />
        <ElementFile Location="MyWebPart\MyWebPart.webpart" />
        <ElementFile Location="MyStyles.css" />
    </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My Module Feature.
• It will be deployed as a Web Site feature, since it's Scope value is Web.
• It references a single element manifest file: Modules.xml.
• It references several element file files. You must reference separately, using these elements, each file you wish to include in the module.

Element Manifest

The element manifest file can have any name you wish (in this example it's called Module.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <Module> element which is used to deploy Files to SharePoint web sites.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    
    <!-- Page Module -->
    <Module Name="Pages" Url="" Path="">
        <File Url="default.aspx" 
              NavBarHome="True" 
              IgnoreIfAlreadyExists="TRUE" 
              Type="Ghostable">

            <!-- Places Web Part on Page -->
            <AllUsersWebPart WebPartZoneID="Left" WebPartOrder="1">
                <![CDATA[
                  <webParts>
                    <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
                      <metaData>
                        <type name="MyWebPart, 
                                    MyWebPart.MyWebPart, 
                                    Version=1.0.0.0, 
                                    Culture=neutral, 
                                    PublicKeyToken=1255988569cf0248" />
                        <importErrorMessage>
                            Cannot import My Web Part.
                        </importErrorMessage>
                      </metaData>
                      <data>
                        <properties>
                          <property name="Title" type="string">
                            My Web Part
                          </property>
                        </properties>
                      </data>
                    </webPart>
                  </webParts>
                ]]>
            </AllUsersWebPart>
            
            <!-- Places a List View for a Discussion Board -->
            <View List="Lists/Discussions" 
                  BaseViewID="4" 
                  Name="Discussions" 
                  WebPartZoneID="Left" 
                  WebPartOrder="2"/>

            <!-- Places a List View for a Document Library -->
            <View List="MyDocuments" 
                  BaseViewID="10" 
                  Name="My Documents" 
                  WebPartZoneID="Left" 
                  WebPartOrder="3"/>

            <!-- Customizes Navigation -->
            <NavBarPage Name="$Resources:core,nav_Home;" 
                        ID="1002" 
                        Position="Start" />
        </File>
    </Module>
    
    <!-- Master Page Module -->
    <Module Name="Master Pages" List="116" Url="_catalogs/masterpage">
        <File Url="MyMasterPage.master" Type="GhostableInLibrary" />
    </Module>

    <!-- Document Module -->
    <Module Name="Documents" List="101" Url="MyDocuments">
        <File Url="MyDocument.docx" Type="GhostableInLibrary" />
    </Module>

    <!-- Web Part Module -->
    <Module Name="WebParts" List="113" Url="_catalogs/wp">
        <File Path="MyWebPart\MyWebPart.webpart"
              Url="MyWebPart.webpart"
              Type="GhostableInLibrary" />
    </Module>

    <!-- Style Sheet Module -->
    <Module Name="Stylesheets" List="101" Url="Style Library">
        <File Url="MyStyles.css" Type="GhostableInLibrary" />
    </Module>
</Elements>

The example above provisions five different files in a SharePoint web site:

• An ASPX web page (web part page) to the root of the web site. This web page contains:
  • A MyWebPart Web Part (on web part zone Left)
  • A List View Web Part that shows a view of a discussion board list
  • A List View Web Part that shows a view of a document library
• A Master Page to the Master Page Gallery of the web site
• A document to a Document Library of the web site
• A web part to the Web Part Gallery of the web site
• A style sheet to the Style Library of the web site

The Module Element
The <Module> element is used to specify a Module. There can be any number of modules in a single element manifest. Here is a summary of the possible attributes of this element:

• IncludeFolders - (optional) I could figure out what this attribute is for...
• List - (optional) Type of list where the files included in this module should be provisioned (check the possible values on my post about List Template Features).
• Name - (required) Name of the module (file set).
• Path - (optional) Specifies the physical path of the files, inside the feature folder (C:\Program Files\...\12\TEMPLATE\FEATURES\[feature]). By default, SharePoint assumes the files are in the same folder as the element manifest file. You can also specify the path on each <File> element (see below).
• RootWebOnly - (optional) Boolean value. If TRUE it specifies that the files in this module will only be provisioned on the root web site of a site collection.
• SetupPath - (optional) Specifies the physical path to a folder, inside SharePoint's setup folder (C:\Program Files\...\12\TEMPLATE), that contains the files included in the module.
• Url - (optional) Specifies the virtual path of the folder in which to place the files of the module. This attribute is also used to provision a folder inside a list. If the Path is not specified, the value of this attribute will be used for the physical path also.

The File Element
The <File> element is used to specify a file inside a module. There can be any number of <File> elements inside a <Module> element. See below a list of the possible attributes of this element:

• IgnoreIfAlreadyExists - (optional) Boolean value. If TRUE it specifies that the file should be provisioned even if it already exists on the destination URL.
• Name - (optional) Specifies the virtual path for the file.
• NavBarHome - (optional) Boolean value. If TRUE it specifies that the file will be the destination of the Home link, used in the web site's navigation. This attribute is only used for web pages.
• Path - (optional) Physical path to the file, inside the feature folder (C:\Program Files\...\12\TEMPLATE\FEATURES\[feature]). This attribute is used if you need to specify a different path for each file inside the module. Otherwise, you can use the Path attribute on the Module element.
• Type - (optional) Specifies if the file is to be stored in a Document Library (in this case the value should be GhostableInLibrary) or outside of a list (in this case the value should be Ghostable).
• Url - (required) Specifies the virtual path for the file. If Name is specified, then the value of this attribute is ignored. However, if Path is not specified, the value of this attribute will be used for the physical path.

The AllUsersWebPart Element
The <AllUsersWebPart> element is used when you want to add a generic web part (non-List View web part) to a web part page. It can only be used inside a <File> element that provisions a web part page file. It has only two attributes:

• WebPartOrder - (required) Specifies the vertical position of the web part inside a web part zone.
• WebPartZoneID - (required) Specifies the name of the web part zone.

Inside this element, you can place a CDATA element with the web part's XML description, either using the DWP file schema (also called V2) or the WEBPART file schema (also called V3).
The View Element
The <View> element is used when you want to add a List View Web Part to a web part page. It can only be used inside a <File> element that provisions a web part page file. It has a lot of possible attributes, but I will only list the most common:

• List - (optional) Specifies either the template type of the list (an integer value) or the URL of a list provisioned in the web site (a string value). On most cases, you should use the URL, since there might be two lists of the same type on the web site.
• BaseViewID - (optional) Specifies the ID of the list view to be used.
• Name - (optional) Specifies the name of the view.
• WebPartOrder - (required) Specifies the vertical position of the web part inside a web part zone.
• WebPartZoneID - (required) Specifies the name of the web part zone.

The NavBarPage Element
The <NavBarPage> element is used to define how the navigation items should be created so that other pages link to this one. It can only be used inside a <File> element that provisions a web page file. It has three attributes:

• ID - (required) Specifies the ID for the page. This ID will be used by other pages when defining the relative position of the navigation items.
• Name - (required) Specifies the text that is displayed in the navigation area of other pages that link to this one.
• Position - (optional) Specifies the position of the navigation item on the navigation area of other pages that link to this one. This attribute can have the following possible values:
  • Start - Add the node to the start of the top navigation area.
  • End - Add the node to the end of the top navigation area.
  • Number between 1001 and 2000 - Add the node after another NavBarPage element whose ID matches the number.

The Property Element
The <Property> element is used only inside the <File> element, to define the value of one or more properties of that file, once it is provisioned. It's mostly used to set properties of web part files or document files. It has only two attributes:

• Name - (required) Name of the property to be set.
• Value - (required) Value to set the property with.

Additional Notes

The files included in a module feature element are provisioned in the web site where the feature is activated. However, when the feature is deactivated, the files that belong to the module element are not removed.
You can learn a lot about modules by looking inside the onet.xml files included in each site template (look in C:\Program Files\...\12\TEMPLATE\SiteTemplates). These files include a <Modules> element which shares the same schema as the Module Features.

8.SharePoint 2007 Deployment: Custom Action Features

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the creation of custom actions in a SharePoint site.
You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

Custom Actions

Custom actions are links, toolbar buttons and menu items that you can add to or hide from the SharePoint's user interface. Each custom action exists in a specific location, and depending on that location, can be a part of a group of actions.
With a custom action feature, you can:

• Add a new Custom Action Group which can be used to group custom actions in a specific options screen;
• Add a new Custom Action which can be a new option in a settings screen, a new menu item, or a new toolbar button;
• Hide an existing Custom Action whether that action is the result of custom action feature or it belongs to SharePoint's out-of-the-box features.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with custom action elements can be deployed to all the scopes, that is, Farm, Web Application, Site Collection and Web Site.
The correct scope must be chosen according to the group and location of the custom action being added or hidden. Note that you can't mix feature elements with different scopes on the same feature.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="My Custom Action Feature"
         Description="Adds Custom Actions to the Web Site."
         Scope="Web"
         Version="1.0.0.0">
    <ElementManifests>
        <ElementManifest Location="CustomActions.xml"/>
    </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My Custom Actions Feature.
• It will be deployed as a Web Site feature, since it's Scope value is Web.
• It references a single element manifest file: CustomActions.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it's called CustomActions.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of three feature elements:

• <CustomActionGroup> used to create new custom action groups;
• <CustomAction> used to create new custom actions;
• <HideCustomAction> used to hide existing actions.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <!-- Custom Action Group -->
    <CustomActionGroup
        Id="MyActionGroup"
        Description="This group contains all my custom actions."
        Title="My Action Group"
        Location="Microsoft.SharePoint.SiteSettings"
        Sequence="30" />
    <!-- Custom Action in Custom Action Group -->
    <CustomAction
        Id="MyCustomAction"
        Description="This link is a custom action."
        Title="My Custom Action"
        GroupId="MyActionGroup"
        Location="Microsoft.SharePoint.SiteSettings"
        Rights="ManageWeb"
        RequireSiteAdministrator="FALSE"
        Sequence="20">
        <UrlAction Url="~sitecollection/_layouts/MyCustomPage1.aspx" />
    </CustomAction>
    <!-- Custom Action in Site Actions Menu -->
    <CustomAction
        Id="MyNewCustomAction"
        Description="This menu item is a new custom action."
        Title="My New Custom Action"
        GroupId="SiteActions"
        Location="Microsoft.SharePoint.StandardMenu"
        ImageUrl="/_layouts/MyActionIcon.jpg"
        Sequence="10">
        <UrlAction Url="~sitecollection/_layouts/MyCustomPage2.aspx" />
    </CustomAction>
    <!-- Hide Custom Action -->
    <HideCustomAction
        Id="HideDeleteWeb"
        GroupId="SiteAdministration"
        Location="Microsoft.SharePoint.SiteSettings"
        HideActionId="DeleteWeb" />
</Elements>

The <CustomActionGroup> Element

The <CustomActionsGroup> element is used to create custom action groups that can contain custom actions. In the sample above, a new custom action group, named My Action Group, is added to the Site Settings screen.
The following attributes can be used with this element:

• Id - (optional) Specifies a unique identifier for this group. It can be a GUID or a unique term, for example "SiteManagement".
• Description - (optional) Description for the custom action group.
• Title - (required) Title of the custom action group, shown to the user in the UI.
• Location - (required) Specifies the place where the custom action group will be placed
  • Microsoft.SharePoint.SiteSettings - Site Settings screen
  • Microsoft.SharePoint.ContentTypeSettings - Content Type Settings screen
  • Microsoft.SharePoint.Administration.Operations - Operations screen in the Central Adminstration web site
  • Microsoft.SharePoint.Administration.ApplicationManagement - Application Management screen in the Central Administration
• Sequence - (optional) Order of the custom action group in the list of groups that exist in the specified location.

The <CustomAction> Element

The <CustomAction> element is used to create a new custom action in the UI. In the above samples, two custom actions are created:

• A custom action (named My Custom Action) in a custom action group (named My Action Group) in the Site Settings screen.
• A custom action (named My New Custom Action) in an existing action group (which is the Site Actions menu).

The following attributes can be used with this element:

• Id - (optional) Unique identifier to the custom action. The ID can be GUID or unique term, for example, "MyCustomAction".
• Description - (optional) Description for the custom action. It will be displayed as a tooltip or sub-description for the action, depending on its location.
• Title - (required) Title for the custom action.
• GroupId - (optional) Specifies an action group inside which to place the custom action. If this custom action is contained inside a custom action group, the value of this attribute must match the value of the Id attribute of the <CustomActionGroup> element.
• Location - (required) Specifies the location for this custom action. If this custom action is contained inside a custom action group, the value of this attribute must match the value of the Location attribute of the <CustomActionGroup> element. Check the possible values below, in the Locations and Group IDs section.
• ImageUrl - (optional) Address of the image to use as the icon for this custom action. Note that, in certain locations, the custom actions don't have an icon.
• Rights - (optional) Specifies a set of permissions that the user must have in order for the link to be visible. If omitted, the action always appears. To specify multiple values, separate them using commas (which means the user must have all the permissions specified). Check the possible values below, in the Action Rights section.
• RequireSiteAdministrator - (optional) TRUE to specifiy that the user must be a site administrator to see the custom action. The default value is FALSE. This attribute is not supported if the custom action is to be placed in the context menu for a list item.
• Sequence - (optional) Specifies the order of the custom action inside its action group.
• ContentTypeId - (optional) Specifies the ID of the content type to associate with the custom action.
• ShowInReadOnlyContentTypes - (optional) TRUE to specify that the action should only appear in the Manage Content Type screen, for Read Only Content Types. The default value is FALSE.
• ShowInSealedContentTypes - (optional) TRUE to specify that the action should only appear in the Manage Content Type screen, for Sealed Content Types. The default value is FALSE.
• ControlAssembly - (optional) Specifies the fully qualified name of the assembly of the control that supports the custom action. This attribute is used in conjunction with the next one.
• ControlClass - (optional) Specifies the name of the class of the control that supports the custom action. This attribute is used in conjunction with the previous one.
• ControlSrc - (optional)
• RegistrationType - (optional) Used to specify the type of attachment in per-item custom actions. The possible values are:
  • ContentType
  • FileType
  • List
  • ProgId
• RegistrationId - (optional) Depending on the RegistrationType value, this attribute can hold a Content Type ID, a File Type identifier, a List ID or a Program identifier.

The <UrlAction> Element

The <UrlAction> element is used inside the <CustomAction> element to specify what happens when the user clicks the link (or toolbar button, or menu item). It has a single attribute, Url, which is the address of the page to redirect the user to.
In this URL address you can use a few tokens that SharePoint will replace by the correct values when the user clicks it:

• ~site - relative address of the current web site.
• ~sitecollection - relative address of the root web site of the current site collection.
• {ItemId} - ID (Integer value) of the item being acted upon (if applicable).
• {ItemUrl} - URL of the item being acted upon (only works in document libraries).
• {ListId} - GUID of the list.
• {SiteUrl} - absolute URL of the current web site.
• {RecurrenceId} - Recurrence index (not supported in the context menu of list items).

The <HideCustomAction> Element

The <HideCustomAction> element is used to hide an existing custom action.
The following attributes can be used with this element:

• Id - (optional) Specifies the ID of this hide custom action element.
• GroupId - (optional) Identifies an action group that contains the action.
• Location - (required) Specifies the location of the custom action to hide. Check the possible values in the table below.
• HideActionId - (required) Specifies the ID of the action to hide.

Locations and Group IDs

The location and group ID values identify a specific place where the custom action must be created (or hidden). See below the possible combinations for both attributes.

Description	Location	Group ID
Display form toolbar	DisplayFormToolbar	N/A
Edit form toolbar	EditFormToolbar	N/A
New form toolbar	NewFormToolbar	N/A
List view toolbar	ViewToolbar	N/A
List item context menu	EditControlBlock	N/A
New menu for list and document library view toolbars	Microsoft.SharePoint.StandardMenu	NewMenu
Actions menu for list and document library view toolbars	Microsoft.SharePoint.StandardMenu	ActionsMenu
Settings menu for list and document library view toolbars	Microsoft.SharePoint.StandardMenu	SettingsMenu
Upload documents menu for document libraries	Microsoft.SharePoint.StandardMenu	UploadMenu
Site Actions menu	Microsoft.SharePoint.StandardMenu	SiteActions
Site Settings Site Collection Administration links	Microsoft.SharePoint.SiteSettings	SiteCollectionAdmin
Site Settings Site Administration links	Microsoft.SharePoint.SiteSettings	SiteAdministration
Site Settings Galleries Links	Microsoft.SharePoint.SiteSettings	Galleries
Site Settings Look and Feel links	Microsoft.SharePoint.SiteSettings	Customization
Site Settings Users and Permissions links	Microsoft.SharePoint.SiteSettings	UsersAndPermissions
Site Actions menu for surveys	Microsoft.SharePoint.StandardMenu	ActionsMenuForSurvey
Site Settings links for surveys	Microsoft.SharePoint.SiteSettings	SettingsMenuForSurvey
Content Type Settings links	Microsoft.SharePoint.ContentTypeSettings	N/A
Central Administration Operations page	Microsoft.SharePoint.Administration.Operations	N/A
Central Administration Application Management page	Microsoft.SharePoint.Administration.ApplicationManagement	N/A

Action Rights

Each custom action has its own set of permission requirements which are defined using the Rights attribute of the <CustomAction> element. The list below summarizes the possible values for this attribute.

• AddAndCustomizePages - Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Windows SharePoint Services–compatible editor.
• AddDelPrivateWebParts - Add or remove personal Web Parts on a Web Part Page.
• AddListItems - Add items to lists, add documents to document libraries, and add Web discussion comments.
• ApplyStyleSheets - Apply a style sheet (.css file) to the Web site.
• ApplyThemeAndBorder - Apply a theme or borders to the entire Web site.
• ApproveItems - Approve a minor version of a list item or document.
• BrowseDirectories - Enumerate files and folders in a Web site using Microsoft Office SharePoint Designer 2007 and WebDAV interfaces.
• BrowseUserInfo - View information about users of the Web site.
• CancelCheckout - Discard or check in a document which is checked out to another user.
• CreateAlerts - Create e-mail alerts.
• CreateGroups - Create a group of users that can be used anywhere within the site collection.
• CreateSSCSite - Create a Web site using Self-Service Site Creation.
• DeleteListItems - Delete items from a list, documents from a document library, and Web discussion comments in documents.
• DeleteVersions - Delete past versions of a list item or document.
• EditListItems - Edit items in lists, edit documents in document libraries, edit Web discussion comments in documents, and customize Web Part Pages in document libraries.
• EditMyUserInfo - Allows a user to change his or her user information, such as adding a picture.
• EmptyMask - Has no permissions on the Web site. Not available through the user interface.
• EnumeratePermissions - Enumerate permissions on the Web site, list, folder, document, or list item.
• FullMask - Has all permissions on the Web site. Not available through the user interface.
• ManageAlerts - Manage alerts for all users of the Web site.
• ManageLists - Create and delete lists, add or remove columns in a list, and add or remove public views of a list.
• ManagePermissions - Create and change permission levels on the Web site and assign permissions to users and groups.
• ManagePersonalViews - Create, change, and delete personal views of lists.
• ManageSubwebs - Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites.
• ManageWeb - Grant the ability to perform all administration tasks for the Web site as well as manage content. Activate, deactivate, or edit properties of Web site scoped Features through the object model or through the user interface (UI). When granted on the root Web site of a site collection, activate, deactivate, or edit properties of site collection scoped Features through the object model. To browse to the Site Collection Features page and activate or deactivate site collection scoped Features through the UI, you must be a site collection administrator.
• Open - Allow users to open a Web site, list, or folder to access items inside that container.
• OpenItems - View the source of documents with server-side file handlers.
• UpdatePersonalWebParts - Update Web Parts to display personalized information.
• UseClientIntegration - Use features that launch client applications; otherwise, users must work on documents locally and upload changes.
• UseRemoteAPIs - Use SOAP, WebDAV, or Microsoft Office SharePoint Designer 2007 interfaces to access the Web site.
• ViewFormPages - View forms, views, and application pages, and enumerate lists.
• ViewListItems - View items in lists, documents in document libraries, and view Web discussion comments.
• ViewPages - View pages in a Web site.
• ViewUsageData - View reports on Web site usage.
• ViewVersions - View past versions of a list item or document.

7. SharePoint 2007 Deployment: List Instance Features

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

The feature manifest file contains the generic information about the feature package, and the element manifest files contain the information about each specific type of element that makes up the feature. Since I already explained all the possible contents of the feature manifest file in the above mentioned post, I will focus this one the element manifest that allows the creation of list instances in a SharePoint site.
You can then place these two files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

List Instances

A list instance is a list created by using a list template (as defined in my previous post SharePoint 2007 Deployment: List Template Features). When creating a list this way, you can override some of the list properties set in the template, and you can include data rows that will also be created as list items in the list.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with list instance elements can only be deployed to Web Site scopes, since it creates a list in a specific web site.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="My List Instance Feature"
         Description="Adds a List to the Web Site."
         Scope="Web"
         Version="1.0.0.0">
    <ElementManifests>
        <ElementManifest Location="ListInstance.xml"/>
    </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My List Instance Feature.
• It will be deployed as a Web Site feature, since it's Scope value is Web.
• It references a single element manifest file: ListInstance.xml.

Element Manifest

The element manifest file can have any name you wish (in this example it's called ListInstance.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <ListInstance> element which is used to deploy Lists to SharePoint web sites.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <ListInstance
           FeatureId="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
           Title="My List"
           Description="List created with a feature."
           Id="1036"
           TemplateType="100"
           Url="Lists/MyList">
    </ListInstance>           
</Elements>

This examples creates a list named My List with the URL Lists/MyList. Here is a short explanation of the attributes of the <ListInstance> element:

• FeatureId - (optional) The GUID of the feature where the list template was defined. If this attribute is not present, SharePoint will assume that the list template was defined in this feature.
• Title - (required) Title of the list.
• Description - (optional) Description for the list.
• Id - (required) Unique integer identifier for this list instance. It must be unique across this feature.
• TemplateType - (required) The integer identifier of the list template. This attribute must map to the Type attribute of the list template definition (in the ListTemplate element).
• Url - (required) Site-relative URL where the list will created.

Other Attributes

There are some other less used attributes that one can use in the <ListInstance> element, which are listed below:

• OnQuickLaunch - (optional) True if you want the list to be displayed in the QuickLaunch menu (local navigation).
• QuickLaunchUrl - (optional) Specifies the URL of the view page to open for the list through QuickLaunch navigation.
• RootWebOnly - (optional) True if the list is only created in the root web site of the site collection.

Including Data

When using this type of feature element, you can specify a set of items that will be included when the list is created. For that you must insert a <Data> element inside the <ListInstance> element, as shown below.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <ListInstance
           FeatureId="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
           Title="My List"
           Description="List created with a feature."
           Id="1036"
           TemplateType="100"
           Url="Lists/MyList">
        <Data>
            <Rows>
                <Row>
                    <Field Name="Title">Item 1</Field>
                    <Field Name="CustomField">Custom Data</Field>
                </Row>
                <Row>
                    <Field Name="Title">Item 2</Field>
                    <Field Name="CustomField">New Custom Data</Field>
                </Row>
            </Rows>
        </Data>
    </ListInstance>           
</Elements>

This example shows how to add two list items to the list instance. For each of the list items, two fields are updated: Title and CustomField.

6.SharePoint 2007 Deployment: List Template Features ant Types of list

Summary

This post is about developing features to create list templates in a SharePoint site. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.

Package Structure

As I mentioned previously in the post SharePoint 2007 Deployment: Creating and Using Features, to build a feature you need to create the following files:

• The feature manifest file (which must be named feature.xml)
• One or more element manifest files

Additionally, a list template must include a third file, called schema.xml, that contains the list definition. This file must be placed in a subfolder with the same name of the list template that is being defined.
You can then place these three files inside a Solution following the instructions in the post SharePoint 2007 Deployment: Creating Solutions, to provide an easy way to deploy the feature (or upgrade it).

List Templates

A list template is a reusable definition of a SharePoint list that is used to create lists. You can create list templates in one of two ways:

• Using a feature, just as described in this post.
• Using the SharePoint interface

To create a list template using the SharePoint interface, you only need to access the list's settings screen, and click on Save As Template. This will save the list template as a .stp file in the List Templates Gallery. This gallery stores only the custom list templates created through the SharePoint interface.
One additional note about list templates stored as .stp files is that they don't store a complete list definition (like the feature does) but rather a set of customizations performed on an existing list definition. This means that, although you can copy the file and deployed it to a different SharePoint farm, you must ensure that the original list definition that was customized to create the template also exists in the destination farm.

Allowed Scopes

The scopes to which a feature can be deployed, are dictated by the types of elements included in it. A feature with list template elements can only be deployed to Site Collection or Web Site scopes.

Feature Manifest

I will only present a simple feature manifest, since the additional options were presented in the above mentioned post.

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
         Title="My List Template Feature"
         Description="Adds my My List Template."
         Scope="Web"
         Version="1.0.0.0">
    <ElementManifests>
        <ElementManifest Location="MyListTemplate.xml" />
        <ElementFile Location="MyListTemplate\schema.xml" />
    </ElementManifests>
</Feature>

Notes about this feature manifest:

• The title of the feature is My List Template Feature.
• It will be deployed as a Web Site feature, since it's Scope value is Web.
• It references a single element manifest file: MyListTemplate.xml.
• It references an element file, schema.xml, which is the file that contains the list definition and must be located in a subfolder with the name of the list template (MyListTemplate in this case).

Element Manifest

The element manifest file can have any name you wish (in this example it's called MyListTemplate.xml), but it's root element must be <Elements>. Inside this root element, you can place any number of feature element descriptions. In this example I will present the use of the <ListTemplate> element which is used to deploy List Templates.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <ListTemplate
        FeatureId="5DFD12AF-D0AA-4c63-8FB8-C49DB1191083"
        BaseType="0"
        Category="Custom Lists"
        Name="MyListTemplate"
        DisplayName="My List Template"
        Description="My Custom List Template."
        DisableAttachments="TRUE"
        DisallowContentTypes="TRUE"
        EnableModeration="FALSE"
        FolderCreation="FALSE"
        Hidden="FALSE"
        HiddenList="FALSE"
        OnQuickLaunch="TRUE"
        SecurityBits="11"        
        Sequence="500"
        Type="100"
        VersioningEnabled="FALSE">
    </ListTemplate>
</Elements>

This example creates a list template named MyListTemplate which is based on the Custom List template. Here is a short explanation of the attributes of the <ListTemplate> element:

• FeatureId - (optional) The GUID of the feature in which this list template is defined. This is an optional attribute but it's useful to include it since each list template is uniquely identified by is Type inside a specific Feature.
• BaseType - (required) Specifies the base type, or default schema, for lists created using this template. Like I mentioned in a previous post (WSS Tip #16: List Base Types) this attribute can have one of five possible values:
  • 0 (Generic List)
  • 1 (Document Library)
  • 3 (Discussion Forum)
  • 4 (Survey)
  • 5 (Issues List)
• Category - (optional) Specifies which category a list created from this template belongs to. It can assume one of the following values:
  • Libraries
  • Communications
  • Tracking
  • Custom Lists
• Name - (required) Specifies the internal name of the list definition. No spaces or special characters can be used. This name is also used to find the folder that contains the schema.xml file that has the list definition.
• DisplayName - (required) Specifies the name of the list template that will be shown to the user in the Create screen.
• Description - (optional) Specifies the description of the list template.
• DisableAttachments - (optional) Specifies if the list created with this template allows items to have attachments. Default value is FALSE (the items are allowed to have attachments).
• DisallowContentTypes - (optional) Specifies if the list created with this template can manage content types, allowing items of multiple content types in the same list. Default value is TRUE (content type management not allowed).
• EnableModeration - (optional) Specifies if the list created with this template will have content approval enabled, which means all items must be approved before they are published. Default value is FALSE (no content approval required).
• FolderCreation - (optional) Specifies if the list created with this template allows the user to create folders, showing the New Folder option in the New button. Default value depends on the type of list. For custom lists, the default value is FALSE (folder creation is not allowed) but for document libraries, the default value is TRUE (folder creation is allowed).
• Hidden - (optional) Specifies if the list template is hidden, which means it will not appear as an option on the Create page. Default value is FALSE (list template is not hidden).
• HiddenList - (optional) Specifies if the list created with this template will be hidden. Do not confuse with the previous option which refers to the list template and not the list created with it. Default value is FALSE (list will not be hidden).
• OnQuickLaunch - (optional) Specifies if the list created with this template will be displayed in the local navigation menu (quicklaunch). Default value is TRUE (list will be displayed on quicklaunch).
• SecurityBits - (required) Defines the item-level permissions for the list created with this template. This attribute is a 2-digit string where the first digit controls the read access, and the second digit controls the edit access. For read access, the digit can be:
  • 1: Users can read all items
  • 2: Users can read only their own items

For edit access, the digit can be:

• 1: Users can edit all items
• 2: Users can edit only their own items
• 4: Users cannot edit items

A notes about this attribute: a user with Manage Lists permission can always read and edit all items, regardless of the value of this attribute.

• Sequence - (optional) Specifies the order of the list template in the Create page. If this attribute is not set, the list template will be placed last in the list of templates (together with other templates that also haven't defined their sequence).
• Type - (optional) This attribute uniquely identifies this list template within the feature that contains it. SharePoint defines a set of list types which are used in the out-of-the-box list templates:
  • 100: Generic List
  • 101: Document Library
  • 102: Survey
  • 103: Links List
  • 104: Announcements List
  • 105: Contacts List
  • 106: Events List
  • 107: Tasks List
  • 108: Discussion Board
  • 109: Picture Library
  • 110: Data Source Gallery
  • 111: Site Template Gallery
  • 113: Web Part Gallery
  • 114: List Template Gallery
  • 115: XML Form Library
  • 120: Custom Grid for a List
  • 200: Meeting Series List
  • 201: Meeting Agenda List
  • 202: Meeting Attendees List
  • 204: Meeting Decisions List
  • 207: Meeting Objectives List
  • 210: Meeting Text Box
  • 211: Meeting Things to Bring List
  • 212: Meeting Workspace Pages List
  • 300: Portal Sites List
  • 1100: Issue Tracking
  • 2002: Personal Document Library
  • 2003: Private Document Library

This attribute might be important if you want to define event handlers that are attached to a specific type of list. I will talk about that scenario on one of the next posts in this series.

• VersioningEnabled - (optional) Specifies if the lists created with this template support versioning of their items. Default value is FALSE (item version is not enabled).

 Other Attributes
There are some less used attributes that one can use in the <ListTemplate> element, which are listed below:

• AllowDeletion - (optional) Specifies if the lists created with this template can be deleted. Default value is TRUE (lists can be deleted).
• AllowEveryoneViewItems (optional)
• AlwaysIncludeContent - (optional) Specifies if the contents are included by default, when lists created with this template are Saved as Templates. Default value is FALSE (content is not included, by default).
• CacheSchema (optional)
• Catalog - (optional) Specifies if the list definition is for a site gallery, list gallery or web part gallery. Default value is FALSE (list is not a gallery).
• Default - (optional) Specifies if new SharePoint sites will include this list. Default value is FALSE (lists are not included in new sites).
• DontSaveInTemplate - (optional) Specifies if a list created with this template should be included when the site that contains it is Saved as Template. Default value is FALSE (list is included in custom site template).
• EditPage - (optional) Specifies the path to a custom application page (/_layouts) to use when editing list properties for list created with this template.
• Image - (optional) Specifies the path to an image that represents the type of list defined by this template.
• NewPage - (optional) Specifies the path to a custom application page (/_layouts) to use when creating a new list based on this template.
• NoCrawl - (optional) Specifies if this list should be crawled and displayed in search results. Default value is FALSE (list is crawled).
• RootWebOnly - (optional, deprecated) Specifies that the lists created with this template can only exist in the root web site of a site collection. Default value is FALSE (lists can exist on any web site).
• SetupPath - (optional) Specifies the path to a folder in the Windows SharePoint Services setup directory (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE) that contains a file to include in the template.
• SyncType (optional)
• Unique - (optional) Specifies that this template can only be used to create lists during site creation, and not through the Create page or the SharePoint object model. Setting this attribute to TRUE has the effect of hiding the list template from the Create page and the list created with it from the web site lists. Default value is FALSE (lists can be created in the interface and through the object model).
• UseRootFolderForNavigation (optional)

List Definition File (schema.xml)

The list definition file (named schema.xml) is included in the feature using an ElementFile tag. Note that this file must be located in a subfolder with the same name as the list template being defined (in this example, MyListTemplate).
This file can be quite large and overwhelmingly complex, since it contains CAML and HTML embedded in the XML. The best strategy to built it is to copy an existing one and making only the necessary changes (which are only a few lines).
For this example, I will use the list definition file from the Custom List template which can be found in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\CustomList\CustList\schema.xml.
List Element
The first thing you must change is the attribute values in the List element. The original file has the following attributes for the main element:

<List xmlns:ows="Microsoft SharePoint" 
      Title="Basic List" 
      FolderCreation="FALSE" 
      Direction="$Resources:Direction;" 
      Url="Lists/Basic List" 
      BaseType="0">

For this example, I will change the above snippet to the one shown below:

<List xmlns:ows="Microsoft SharePoint"
      Title="My List"
      FolderCreation="FALSE"
      Direction="$Resources:Direction;"
      Url="Lists/MyList"
      BaseType="0">

Most of these attributes can be overridden when creating a list based on this template, but it's always a good practice to set the correct display name (Title attribute), default URL (Url attribute) and list base type (BaseType attribute). There are several optional attributes that you can specify to set additional configuration for the list template. For the sake of simplicity, I will not list them in this post.
The List element can have two child elements: Data and Metadata.
Data Element
The Data element is optional and is used to specify a set of rows that will be included in every list created with this template. Below is a sample snippet of this element.

<Data>
    <Rows>
        <Row>
            <Field Name="Title">My Item Title</Field>
            <Field Name="Body">Welcome to my custom list.</Field>
            <Field Name="Country">Portugal</Field>
        </Row>
    </Rows>
</Data>

In the above sample, I'm assuming that the list contains (at least) three fields (named Title, Body and Country, respectively) and I'm setting their values for a single row.
Metada Element
The Metadata element holds the definition of the list. It can have several child elements:

• Default - Contains the default form definitions used in lists created through the list definition.
• ContentTypes - Contains references to content types to associate with list created through the list definition.
• DefaultDescription - Sets the default description that appears in the title area of list views.
• DocumentLibraryTemplate - Specifies which file servers as the template document for items of a document library.
• Fields - Contains the field definitions for that belong to the list template.
• Forms - Contains the collection of forms used for lists create through the list definition.
• Toolbar - Contains the configuration for the toolbar used in the list views in list created through the list definition.
• Views - Contains the definition of the views used in a list created from this template.

Most lists will only need a subset of these, and I will show only three of them, which are the ones that must be changed in this example: ContentTypes, Fields and Views.
ContentTypes Element
The ContentTypes element specifies which content types will be associated with the lists created with this template. Each content type is referred through a ContentTypeRef child element as shown below.

<ContentTypes>
    <ContentTypeRef ID="0x0100C5647A362F236548B218C15302286758">
        <Folder TargetName="MyContentType" />
    </ContentTypeRef>
    <ContentTypeRef ID="0x0120" />
</ContentTypes>

The ContentTypeRef element has a required attribute ID, that specifies the ID of the referred content type. The Folder child element is optional, and is used to specify the relative folder path (inside the list's root folder) for the content type's resource folder. Most of the times, it's value is the name of the content type.
Fields Element
The Fields element is used to list the fields that should be included in the list. Two important notes about this element:

• You don't need to specify fields that were already defined in the base list.
• You must specify all other fields, even those that belong to a content type already associated with the template (via ContentTypes element).

<Fields>
    <Field 
        Type="Text"
        DisplayName="Body"
        ID="{b402db15-ee44-4ec4-89e3-23e10a8fc64c}"
        SourceId="0x0100C5647A362F236548B218C15302286758" 
        StaticName="Body"
        Name="Body" />
    <Field
        Type="Text"
        DisplayName="Country"
        Required="FALSE"
        MaxLength="255"
        Group="My Fields"
        ID="{f402db10-eb44-4ba4-20f3-73e13e8fe42c}"
        SourceId="0x0100C5647A362F236548B218C15302286758"
        StaticName="Country"
        Name="Country" />
</Fields>

In the above sample, I defined two fields (Body and Country). I didn't define the Title field because it is already defined in the base list. The attributes of the Field element are the same that were explained in the post SharePoint 2007 Deployment: Site Column Features.
Views Element
The Views element is used to specify the views that will be used in the lists created through this list template. It has a View child element for each view to be created, which is a rather complex element, with several possible attributes and child elements. Most of the times, you'll only need to edit the ViewFields and the Query child elements of the View element, as shown in the sample below.

<Views>
    <View BaseViewID="0" 
          Type="HTML" 
          WebPartZoneID="Main" 
          DisplayName="My View" 
          DefaultView="TRUE" 
          SetupPath="pages\viewpage.aspx" 
          ImageUrl="/_layouts/images/generic.png" 
          Url="AllItems.aspx">
        (...)
        <ViewFields>
            <FieldRef Name="Attachments" />
            <FieldRef Name="LinkTitle" />
            <FieldRef Name="Body" />
            <FieldRef Name="Country" />
        </ViewFields>
        <Query>
            <OrderBy>
                <FieldRef Name="Title">
                </FieldRef>
            </OrderBy>
        </Query>
    </View>
</Views>

In the above sample, the defined view is called My View and contains four fields: Attachments, LinkTitle, Body and Country, and the items are ordered using the Title field.