Provision a Content Type with a Document Template using a Feature – Part 2

• Provision a Content Type with a Document Template using a Feature – Part 1.
• Provision a Content Type with a Document Template using a Feature – Part 2.

In this post we’ll provision a content type with a document template using a feature.

To create the feature we’ll use Visual Studio and WSPBuilder, and we’re going to create 2 content types;

• 1 which provisions the document template into the _cts/{content type name} folder
• 1 which provisions the document template into the _layouts folder.

Before we start my project structure looks like this;

Project Structure

Create a standard site collection  scoped feature;

<?xml version="1.0" encoding="utf-8"?>
<Feature  Id="a4c8c426-6d87-4b2f-b109-e7f00b7d6c15"
          Title="My Test ContentTypes"
          Description="Description for MyTestContentTypes"
          Version="12.0.0.0"
          Hidden="FALSE"
          Scope="Site"
          DefaultResourceFile="core"
ActivateOnDefault="FALSE"
          xmlns="http://schemas.microsoft.com/sharepoint/">
	<ElementManifests>
		<ElementManifest Location="contenttypes.xml"/>
		<ElementFile Location="templates\doc1.dotx"/>
	</ElementManifests>
</Feature>

Now create the contenttypes.xml manifest file;

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<ContentType ID="0x0101002880177DFDC248c38C745E1D664A5FC5"
					 Name="Doc Sample"
					 Description="Test CT with DT"
					 Group="_Custom">
		<FieldRefs />
		<DocumentTemplate TargetName="doc1.dotx"/>
	</ContentType>
	<Module Name="PopulateDocTemplates"
			  Url="_cts/Doc Sample"
			  RootWebOnly="TRUE"
			  Path="templates"
			  SetupPath="Features\MyTestContentTypes\templates">
		<File Url="doc1.dotx" />
	</Module>
	<ContentType ID="0x0101009889C18B0DFB4fc58C8D35C9AB4EDE03"
					 Name="Function Sample"
					 Description="Test CT 2 with DT"
					 Group="_Custom">
		<FieldRefs />
		<DocumentTemplate TargetName="/_layouts/1033/LCFT/templates/doc2.dotx"/>
	</ContentType>
</Elements>

* If your content type does not include any additional fields above those of the inherited content type, you must still include the empty <FieldRefs /> element.

The 1st content type (Doc Sample) provisions the document template into the _cts/Doc Sample folder using a Module.

The 2nd content type (Function Sample) provisions the document template into the file system in the _layouts/1033/LCFT/templates folder as a template file.

Build and package up the WSP, deploy and activate the feature.

Provision a Content Type with a Document Template using a Feature – Part 1

• Provision a Content Type with a Document Template using a Feature – Part 1.
• Provision a Content Type with a Document Template using a Feature – Part 2.

Provisioning a SharePoint Content Type using a feature is straightforward enough, whats not so well documented is configuring the content type to have a custom document template. But, actually this too is pretty easy.

Along the way I’ve found these blogs pretty useful;

• Nick Grattan
• Ed Hild
• K2

Background.

You can configure a Content Type to have a custom document template using the UI as shown;

Configure content types document template

The second option allows you to upload a template which will be stored in SharePoint in a folder called _cts/{content type name}. If you use SharePoint Designer you’ll see this folder in the root of your site/site collection. The first option allows you to specify a URL to the document template to use.

If you specify just the document template name as the URL, as shown above, SharePoint assumes the document template is stored in the _cts/{content type name} folder, and will attempt to load it from there. This is what the second option actually does, it uploads the document template to the _cts/{content type name} folder and sets the URL of the template to the template filename.

You can however use the first option to set the URL of the template to be a full, server relative URL of an existing template, as shown below.

Configure content type document template using full URL

Whats the difference you ask? Well for most people there is no difference at all except in the way you provision the document templates themselve (using a feature) – more on that in Part 2. However based on my own experience a difference becomes apparent when you start using multiple content types inside a single document library.

In this scenario, when you select a specific content type from the New drop down menu;  the Office client loads using the correct template but doesn’t save the document back to SharePoint using the content type you selected, instead using the default content type of the document library. This problem and a possible solution is described by Nick Grattan in this post. While the solution is a good one, it’s difficult to provision using a Feature.

Another, curious, observation I’ve found concerns the location and therefore the URL of the document template configured against the content type.

I mentioned previously that the document template could be a full, server relative URL, and in my example (the Function Sample content type) the location of the template was in the _layouts folder. In this scenario, the behaviour I’ve seen is this;

Selecting New -> Function Sample from SharePoint, opens Word using the correct document template. So far this is normal behaviour. When saving though, Word displays a dialog box allowing you to choose which Content Type the document is to be saved as;

Choosing the Content Type from the Word client

I have no idea why this seems to be the case, but in my environment, it’s at least consistent.

In Part 2, I’ll demonstrate how content types with document templates can be provisioned.

6 Part Series: Customizing the User Experience of SharePoint

There is a great 6 part series on customizing the user experience by Bjørn Furuknap on SharePoint magazine.

The series covers the following topics;

Part 1: Overview of the default SharePoint interface from a technical point of view

In the first article we will look at how the default SharePoint interface is built. We will look at a site, going from top-down, explore some of the the default lists, the fields used to create the basic field types, which content types are available, and how list forms are rendered.

Part 2: Modifying the default experience

This article will show you which options are available for you to modify and improve the default setup. Learn how to override the default rendering of fields or forms without voiding your supported state.

Part 3: Lists and custom list forms

The third article will cover the basics of customizing lists using different views, custom list forms, and fields.

Part 4: Content types user interface

The next article will explore how you can utilize content types to display different input forms and display forms.

Part 5: Custom fields deep dive

Ever wanted to create a new field type? SharePoint enables you to do this and it is a very powerful tool for customizing the user experience.

Part 6: Fast track to feature generation

Writing custom lists with content types by hand can take a massive amount of time. In the final installment I will share with you some tools and techniques that makes list, field, and content type generation very fast.

Bjørn also has an excellant article introducing the reader to SharePoint DelegateControl’s.

High CPU Utilization by W3WP.EXE when Deploying Feature based SharePoint Content-Types

I’m developing some Site Columns, Content Types and List Templates and packaging them into a feature for deployment. All is well, the feature deploys and activates just fine, but when I click on the Content Types link under Galleries in Site Settings (http://…../_layouts/mngctype.aspx) the browser just chokes and sits there all day. Everything else slows down too so I look at Task Manager and notice that W3WP.EXE is running at around 95% CPU utilization – not good.

Eventually I manage to get the feature deactivated and uninstalled and start looking at my Content Type CAML, nothing looks wrong so I take a look at the CAML for the OOTB Custom List template ( found in …\12\TEMPLATE\FEATURES\CustomList\CustList\schema.xml ), some time later I notice that the <XmlDocument> tag is missing the NamespaceURI attribute that is present in the Custom List’s version. 

My version:

...
<XmlDocuments>
    <XmlDocument>
        <FormTemplates xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
...

Custom Lists’ version:

...
<XmlDocuments>
    <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
        <FormTemplates xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms">
...

I make my adjustments, redeploy, activate and so on, and the problem is solved.

Originally I’d exported a template content-type from SharePoint using Andrew Connell’s custom STSADM commands, so I guess his -gencontenttypesxml command misses that bit, still great tools though.