Custom Edit/Add/Display forms in SharePoint 2010

Posted: February 24, 2012 in SharePoint 2010

Custom Edit/Add/Display forms in SharePoint 2010

SPS version: SharePoint 2010 Enterprise – CU Dec 2011   

I recently ran into a case where I needed a wsp based solution to provide a custom edit form just for a specific content type. In this specific case we had a content type that would be one of a couple on a document library. This document library would be repeated in many subwebs throughout the site collection. In this case it needed  to implement the codeplex JQuery based filtered dropdown solution.

So yeah I could do this with Designer but it would not provide me as clean and easily implementable solution as I desired. What we came up with was a solution that was built into the schema for custom content types in SharePoint. Specifically, this is nested in the XMLDocuments element within the schema ( . Within this element there is a “FormTemplates” element with “Display”, “Edit”,”New” elements. These elements allow you to set a content type to load a custom ascx control for your edit, display, and new item forms. So long as you deploy the ascx to the ControlTemplates folder that is. And the name in the elements matches the name of the ascx (minus the ascx).

An example of its usage can be seen below:


<XmlDocument NamespaceURI=””&gt;

<FormTemplates xmlns=””&gt;







The “DocumentLibraryForm” shown in the Display element is the default form. The forms shown in the Edit and New elements are custom forms with the JQuery based dropdowns. So I rolled this into a WSP and deployed it along with my ASCX and life should be bliss…

Should be but it was not. Despite a plethora of documentation that says this SHOULD work. It did not. Further investigation showed that SharePoint 2010 was removing these values from the content types that inherited from this base type. Now, there was some documentation which suggested that removing “Inherits=”TRUE” from the content type itself would fix this. However, I needed this type to inherit from the default document type and the some additional content types to inherit from it. No matter how I ran this, during that inheritance chain, SPS 2010 always dropped this value.

After much chatting on discussion boards and some Microsoft employees, the end solution was to insert some code into the feature activated event for the feature that created the lists that utilized this content type. After grabbing a reference to the SPContentType object for the content type(s) that needed the custom form, you can set the “NewFormTemplateName”, “EditFormTemplateName”, “DisplayFormTemplateName” values as you see fit and this time they will stick.

Should anyone find any other ways around this, please feel free to throw up a comment. It was a bit of a pain but once all this was worked out, it really simplified the deployment for this solution and provided a rather surgical way to push in custom add/edit/display forms as you see fit within a farm.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s