A while ago I stumbled upon a serious design limitation regarding Content Types and centralized document templates. What then followed was a series of testing, phone calls with Microsoft, finding alternative solutions and deep dive into Office Open XML.
Request from the customer
“We want to use MOSS 2007 to create a collaboration site per project for our 400+ projects. These collaboration sites all use the same Content Types and document templates. We want to centrally manage those document templates so that we don’t need to make the same change 400+ times.”
Approach
Due to sizing we architected a solution with a dozen of Site Collections that would each hold a collection of project sites. We ‘Feature’-ized our Content Types and Site Columns so that they could quickly be activated on all Site Collections and used by the child sites. Document templates would be stored in a central document library and we would link to them in the Content Types on the project sites.
First issue
Linking to document templates really doesn’t play well with the Document Information Panel (DIP). I have blogged about this here:
Centralizing Document Templates in a library- Document Information Panel shows incorrect properties
We proposed a solution where the document templates in the central library would be pushed to the Content Type resource folder on site level. The code to perform the push would have to connect to the Site Collections, copy the template to the resource folder (http://sitecollectionurl/_cts/contenttypename) and link template and Content Type together.
When a Site Content Type is associated with a List it will be a List Content Type inheriting from the Site Content Type and the document template will be copied to the List Content Type resource folder (http://sitecollectionurl/listurl/Forms/contenttypename).
Second issue
Did I tell you that the column values (metadata) have different values based on the project site ? So when a project site is created we automatically update the List Content Type Column default value with the values for that specific project site. Unfortunately this is not supported when working with Office 2007 file formats because they only react on changes to the Site Column.
Consider the following scenario:
1) Set up a document library with a Content Type that has a text column with a default value
2) Upload a new .doc or .docx as Content Type template
TEST 1) Create a new document:
.DOC: the DIP will contain the text column with the default value
.DOCX: the DIP will contain the text column with the default value
3) In SharePoint, modify the default value of the text column
TEST 2) Create a new document:
.DOC: the DIP will contain the text column with the updated default value
.DOCX: the DIP will contain the text column with the original default value
Microsoft confirmed that this is by design.
Third issue
When designing our document templates with Content Controls mapped to our SharePoint fields we didn’t know that internally in the DOCX file it uses a GUID for mapping the Content Control with the SharePoint Metadata XML. For fields (Site Columns) created in the UI or through API this is the SPWeb.ID of where they were created. For fields created declaratively through Features this is the SPList.ID of where their Content Type is associated to.
So some things to notice
- Creating a single document template with Content Controls mapped to your declaratively added Fields cannot be used in two different Document Libraries because the Content Controls lose the connection with Field (because the ID of the List is different and not updated in the Content Control)
- The solution here is to create your fields in the UI or through the API (this could be in a Feature Activating event)
- Copying a document template across Site Collections means different Web ID’s so it also affects fields created in the UI or the API
Finally
In the end we wrote some wrapper classes for Office 2007 file formats using System.IO.Packaging that would manipulate our document templates once they were copied over to a different Site Collection. We also rewrote our Features to create our Fields through the API (SPWeb.Fields.AddFieldAsXml()).
- Remove the SharePoint Metadata XML so that association of the Content Type to a List it would be regenerated automagically
- Loop through every Content Control and find to which Field they were mapped using information in it’s XPath. Then we would update the GUID’s in the Content Control to match the SPWeb.ID
Next time I’ll definitely take these design limitations into account. Lessons learned I’d say !
Word 2007 uses Content Controls to display document fields inside the document (eg. the header). These document fields can be standard fields but also your SharePoint Fields.
By default when the value of a Content Control is empty it will display the Placeholder Text between square brackets as follows in a sample document header:
It is possible to change this Placeholder Text by going into Design Mode and replacing the text in the Content Control.
Make sure that you see the Developer tab in the Word Ribbon. If you don’t see it you can turn it on in the Word Options;
Open the Developer tab and enable Design Mode;
Now the text displayed in the Content Control is actually that one for the Placeholder Text and can be modified as desired. Once you leave design mode the Content Placeholder will return to displaying the original value and have saved the new Placeholder Text.
Removing all text from the Content Control Placeholder Text will result in an error when leaving Design Mode;
The closest you can get to making it appear empty is by using a single space character. Once you exit Design Mode you’ll see the result for those fields that have no value set.
Every once in a while I get the request to manage all document templates centrally in a Document Library. This can easily be done by configuring your Content Types to ‘link’ to the document template by location and then applying those Content Types to lists on several locations.
However there’s a gotcha in Word 2007 with the Document Information Panel.
Consider the following scenario:
- You have a “MyTemplates” Document Library for storing the Word templates (.doc, .docx)
- You have a “Documents” Document Library configured with Content Types linking to your templates as noted above. These Content Types have custom metadata (text fields, date fields, lookup fields, etc.)
- You create a new document with a given Content Type
When the new document opens in Word 2007 the Document Information Panel is showing properties from the “MyTemplates” Document Library instead of your Content Type. Once you save the document it will refresh and show the correct set of properties. If you have required metadata it will prompt you to fill that in before actually saving.
I believe this to be a bug in Word 2007. It has been confirmed by Microsoft that this is a design limitation.
A workaround An alternative solution for some scenario’s could be to set the Content Type of your templates to the target Content Type.
This would of course still not work when you want to use the same template for multiple Content Types.
Definitely something to keep in mind when planning your setup…
I'm normally not into Office Automation but today I needed to extract all embedded files from a Word Document. Those files were Word, Excel and PDF documents. Luckily the majority were Word documents, because the quick solution I whipped up only works for those types, not for Excel or PDF.
Here's the VBA script that loops through the embedded objects, checks if it's a Word document and goes to save it in a new folder.
Sub ExtractFiles()
'
' ExtractFiles Macro
'
'
Dim shape As InlineShape
Dim folderName As String
Dim a As Document
folderName = Replace(ThisDocument.Name, ".", "_")
MkDir folderName
For Each shape In ThisDocument.InlineShapes
If (shape.Type = wdInlineShapeEmbeddedOLEObject) And (InStr(LCase(shape.OLEFormat.IconLabel), ".doc") > 0) Then
shape.OLEFormat.Object.SaveAs (folderName & "\" & shape.OLEFormat.IconLabel)
End If
Next shape
End Sub
The Office 2003 Web Parts can still be installed on WSS 3.0 and MOSS 2007.
STSADM.EXE -o addwppack -filename "Microsoft.Office.DataParts.cab" -globalinstall
For your clients to see the Web Parts correctly rendered they will need the Office 2003 client libraries and Internet Explorer 5.0 or above.
To use either the Spreadsheet Web Part or the PivotView Web Part, you must have Microsoft Internet Explorer 5.01 Service Pack 2 (SP2) or later and the Microsoft Office 2003 Web Components installed on your computer. See the Microsoft Office Web site for more information.
If a computer has Office 2007 Client or no MS Office at all installed, they will need to download and install the client libraries (OWC11) manually.
Screenshot
Links