|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Windows SharePoint Services 3.0 provides a powerful new forms infrastructure that lets you customize existing forms and field rendering controls. SharePoint forms are based on .NET Framework controls, so you can use or extend default SharePoint field controls to build richer forms that enhance user experience of SharePoint data.
The fields used in forms are also ASP.NET controls. You can create custom fields that extend field rendering but inherit the functionality of the default fields. Windows SharePoint Services uses ASP.NET templates to create the static HTML used for layout of forms and field controls. You can customize existing SharePoint control templates, or you can create new templates and customize controls to use the new templates.
Customizing SharePoint forms involves tasks such as the following:
Extending fields by creating custom field types in a FldTypes*.xml file or custom field definitions in a Schema.xml file. Field definitions determine how fields are displayed depending on the mode, in other words, on whether the form is for displaying, editing, or creating a list item. For more information about extending field definitions, see Custom Field Types.
Extending native Windows SharePoint Services field controls for field rendering and data validation. You can create code behind that inherits from SharePoint controls and defines specific logic required for custom form fields.
Creating or customizing control templates for form page layout. You can define control templates that override native controls.
When you create custom form rendering templates in the Microsoft Visual Studio IDE, for example, by copying and pasting code from the default DefaultFormTemplates.ascx file, valid code might raise errors that you can safely ignore.
To check for the correct data type, range, and so on, you can provide client-side script for a field to perform validation of user data, or the form can use server-side code to do validation based on data on the server. You can add validation logic to server-side code in the following ways:
Override the GetValidatedString method in a custom field type that inherits from Microsoft.SharePoint.SPField (or from another field class that inherits from SPField, such as SPFieldText). This approach provides field validation at the object model level, covering cases where users submit data through forms, as well as cases where they add or edit field data directly through the object model.
Override the Validate method to implement validation logic and set the error message for validation failures in a custom field control that inherits from Microsoft.SharePoint.WebControls.BaseFieldControl or from a type-specific control, such as TextField. This approach takes place at field control level and only supports validation on forms.
Windows SharePoint Services does not support cross-field actions, such as for linking multiple fields so that input from one field triggers an action on another field or group of fields. However, you can add custom field controls or validation controls to customized forms. Within your custom controls, access other field controls through the FieldControlCollection property of the Microsoft.SharePoint.SPFormContext object, which can be returned through the SPContext.FormContext property. You can then change the behavior of these controls through postback.