SharePoint 2007 - watch out for FormUrls in a content type feature definition

The MSDN documentation - Custom information in content types talks about how you can define custom edit forms for a SharePoint content type. It specifies how you can define both FormUrls  as well as FormTemplates within a XMLDocument node for a content type - for more information take a look at the Content Type Definition Schema.

I already took a look at how to do this using FormTemplates but I thougth that it would be more straightforward using FormUrls - so I created a new content type - take a look at (Warning - the next snippet does not work correctly - read the whole blog post :-) ...)

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
	<ContentType ID="0x0100F61D86C522AD4f189680304F14134D97"  Name="CustomCT"
		  Description="Content type for testing custom edit forms"
		  Version="0">
		<FieldRefs>
			<FieldRef ID="{0D3CDE70-DFAB-4411-B5D3-17DE7647BC4E}" Name="DemoComment"/>
		</FieldRefs>
		<XmlDocuments>
			<XmlDocument>
				<FormUrls xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms/url">
				<Display>_layouts/mydisplayform.aspx</Display>
				<Edit>_layouts/myeditform.aspx</Edit>
				<New>_layouts/myuploadform.aspx</New>
			</FormUrls>
			</XmlDocument>
		</XmlDocuments>
	</ContentType>
</Elements>

Well, when I tested this - the content type appeared alright but I did not see my custom edit forms. Weird ... But wait - things get worse. When I tried to deactivate the content type using the SharePoint user interface - it did not work - no errors, I just could not deactivate it. Next, I tried to deactivate it using stsadm.exe -  this did not work either. Fortunately, stsadm.exe -o uninstallfeature -name customeditform -force did work. Afterwards I reinstalled the content type feature again - just to make sure that it wasn't a temporary glitch. Then, I tried to run the next code snippet in a console application to check all installed features

 try
            {
                SPSite sitecollection = new SPSite("http://moss");
                SPWeb site = sitecollection.OpenWeb();

                foreach (SPContentType ct in site.ContentTypes)
                {
                    Console.WriteLine(ct.Name);
                }
            }
            catch (SPException ex)
            {
                Console.WriteLine(ex.ToString());
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.ToString());
            }

 

The code just stopped when it needed to enumerate the content types - when in uninstalled the CustomEditForm feature - it ran again without any problems. But wait, then I remembered that I had seen FormUrls being used in SharePoint workflows. If you take a look at the OffWfCommon feature (this is a SharePoint Server 2007 Enterprise Edition feature - you will not see it in WSS 3.0 or in MOSS standard edition)- which deploys the SharePoint workflow task content type - it does use FormUrls.

<?xml version="1.0" encoding="utf-8" ?>
<!-- Copyright (c) Microsoft Corporation. All rights reserved. -->
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <ContentType ID="0x01080100C9C9515DE4E24001905074F980F93160"
        Name="$Resources:WorkflowTaskIP_Name;"
        Description="$Resources:WorkflowTaskIP_Description;"
        Group="_Hidden"
        Hidden="TRUE"
        Version="0">
        <FieldRefs>
        </FieldRefs>
        <XmlDocuments>
            <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms/url">
                <FormUrls xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms/url">
                    <Display>_layouts/WrkTaskIP.aspx</Display>
                    <Edit>_layouts/WrkTaskIP.aspx</Edit>
                </FormUrls>
            </XmlDocument>
        </XmlDocuments>
    </ContentType>
</Elements>

If you want to build your own SharePoint workflows using ASP.NET forms you will need to define a new workflow task content type which inherits from the default SharePoint workflow task content type and here FormUrls work without any problem.

But suppose that you still want to define custom edit forms for your content type (even when it does not inherit) - well it actually seems to work when you do it using code. So you can create a Feature event receiver in which you add your own code to manipulate the FormUrls (I'm not going into details about how to create a feature event receiver - you might want to start by taking a look at SPFeatureReceiver as well as this interesting blog post -WSS v3 solution and feature framework applied to FlexListViewer webpart). Here's a demo code snippet to register a custom edit form:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            SPWeb site = (SPWeb)properties.Feature.Parent;

            foreach (SPList list in site.Lists)
            {
                //If list uses specific content type then update
                foreach (SPContentType c in list.ContentTypes)
                {
                    if (c.Name.ToLower() == "customeditformct")
                    {
                        c.EditFormUrl = @"/_layouts/Dolmen/myeditform.aspx";
                        c.Update();
                    }
                }
            }

        }

Important conclusion: Only use a FormUrls section within your content type when you inherit from the SharePoint workflow task content type. You can however use the EditFormUrl property allthough I still need to test this one thoroughly. If you have some feedback or experienced something similar leave a comment.

Technorati tags: sharepoint, sharePoint+2007, moss+2007, moss, wss3, features, workflow, csharp, microsoft