How SharePoint Forms Work
Last modified: July 07, 2010
Applies to: SharePoint Foundation 2010
Each list type generally has a set of display, edit, and new form ASPX pages (DispForm.aspx, EditForm.aspx, and NewForm.aspx) that are provisioned when lists are provisioned. These ASPX pages are provisioned into the "content space." In other words, they are not located in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS, and they do not operate through the /_layouts virtual directory. For document libraries, these pages are instead provisioned within a hidden subfolder of the list called forms. For other SharePoint lists, the pages are provisioned under the list root folder. Each of these ASPX pages contains a Microsoft.SharePoint.WebPartPages.ListFormWebPart object that serves to render the form.
Microsoft SharePoint Foundation 2010 uses Microsoft ASP.NET to display forms. Each form logically consists of a set of controls (for example, a control for the toolbar). A special control called an iterator (Microsoft.SharePoint.WebControls.ListFieldIterator) is used to iterate the collection of list fields and add each field to the form.
In previous versions of SharePoint Foundation you generally customized list item forms by modifying the form definitions in the Schema.xml file of a list. The Form element contained the rendering details for a specific type of form, including Collaborative Application Markup Language (CAML) subelements that defined the HTML and script to insert in the page. SharePoint Foundation uses the template functionality built into Microsoft ASP.NET control templates.
Although forms can still be defined in Schema.xml, you can now take advantage of the rich functionality available through ASP.NET control templates to modify forms. Control templates involve a mix of HTML elements and child controls, and they insert HTML into the containing page or control. By building a hierarchy of control templates, you can effectively create an inheritance model for your Web applications, thus reusing your code more efficiently.
Through custom form templates, you can modify how list item forms are rendered. In the Schema.xml file of the list definition, you can specify per list type through the Template attribute the IDs of control templates to use to render the forms. You must specify the Template attribute for any form in which you want to implement a custom template, which can be the same template or different templates. If you do not specify a custom template for a form, SharePoint Foundation by default implements the default template. Custom control templates must be defined within an .ascx file in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\CONTROLTEMPLATES. For information about how to use Microsoft Visual Studio to create a user control that works in SharePoint Foundation, see How to: Create a User Control for a SharePoint Application Page or Web Part.
Overriding a default SharePoint Foundation template changes the form's behavior on the whole server farm, and it prevents the form from retaining default template behavior when you update versions. Instead, create your own list template that uses a custom form template to implement custom behavior.
As an example, you can override how all survey list item forms are rendered. The survey list definition in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES\SurveysList\Survey\Schema.xml uses the Template attribute to specify ListForm as the template to use for Display item forms, and the SurveyForm template for Edit and New item forms. This means there are control templates whose IDs equal ListForm and SurveyForm that are located within the \ControlTemplates folder, and you can globally replace the default form templates used for survey list item forms by overriding these templates. Define custom templates with the same IDs in a custom .ascx file.
There can only be only one template with an ID equal to ListForm or SurveyForm that will be used, so use this extensibility feature sparingly. Having duplicate IDs for custom templates is not supported and can lead to unpredictable results.
It is also possible to register custom form templates by content type. If you have a specific content type, it is possible for that content type to declare a custom form to use in place of the standard document library form used by default in document libraries. For information about how to declare custom forms for a content type, see FormTemplates Schema Overview.
Other means for displaying forms are supported. You cannot remove the existing ListFormWebPart control from a list form page, but you can hide the control. You can then add, for example, a DataFormWebPart object and use XSLT to render forms for items. You can also set the form page URL on the content type (DisplayFormUrl, EditFormUrl, or NewFormUrl property) to redirect users to a custom form page. In addition, you can use the Microsoft.SharePoint.WebControls.SPDataSource control to bind the form to plain ASP.NET controls and to update data.
Although it is possible to add Web Parts to the Display, Edit, and New forms for list items (DispForm.aspx, EditForm.aspx, and NewForm.aspx), doing so is not recommended or supported in SharePoint Foundation. Adding Web Parts to list view pages (AllItems.aspx) is supported.