What's New: Custom Field Rendering Enhancements
Applies to: SharePoint Foundation 2010
Microsoft SharePoint Foundation 2010 makes two significant changes to the way that you define how custom field types render.
XSLT Stylesheet Rendering on List Views
In Windows SharePoint Services 3.0, fields were rendered on list view pages by a RenderPattern element in a field definition file, fldtypes*.xml. In SharePoint Foundation 2010, fields are rendered on list view pages by XSLT stylesheets. Consequently, you now define the rendering of your custom field types by creating a custom XSLT stylesheet rather than adding a custom RenderPattern element to a field type definition. See How to: Create a Custom Field Type Definition and Understanding the FldTypes.xml File for more information about field type definitions. See Overview of XSLT List View Rendering System and How to: Customize the Rendering of a Field on a List View for more information about XSLT rendering and how to customize it.
RenderPattern Elements are Now Obsolete
In Windows SharePoint Services 3.0, fields were also typically rendered in Display mode by means of a RenderPattern element in a field definition file. It was also possible, although rare, to render a field in Edit and New modes with a RenderPattern element. It was more common to render fields in Edit and New modes with a user control (ASCX), known as a RenderingTemplate, and it was possible to use a user control to render a field in Display mode. In SharePoint Foundation 2010, custom fields should always be rendered with user controls in all three modes. Although some long-standing built-in fields still use a RenderPattern element, for development of custom fields RenderPattern elements are obsolete.
PropertySchema Elements are Now Obsolete
In Windows SharePoint Services 3.0, when a custom field had a variable property (that is, a property with a different value on different lists), a control was needed on the New Site Column, Change Site Column, Create Column, and Change Column pages so that users could set the property value. One of the ways that custom field designers could define the rendering of this control was with a PropertySchema element in a field definition file. This method is now obsolete. You should create an editing control as a user control (ASCX). Point your custom field to the user control by setting the FieldEditorUserControl property. For more information about such editor controls, see Custom Field Type Property Rendering and How to: Create an Editor Control for a Field Type Property.
Backward Compatibility
If there is no user control (RenderingTemplate) for a field, the runtime looks for a RenderPattern element in the field type definition file and, if found, uses it. One implication of this behavior is that custom fields that you created for versions earlier than SharePoint Foundation 2010 can still use their existing field type definitions with RenderPattern elements for Display, Edit, or New mode.
SharePoint Foundation 2010 will not automatically render your legacy custom fields on list views by using the RenderPattern in the field type definition for the field. However, if you do not want the default rendering that is given to the field by the XSLT stylesheet, you can re-enable the RenderPattern by adding a <Field Name="CAMLRendering">TRUE</Field> element to the field type definition. For more information, see Understanding the FldTypes.xml File and RenderPattern Element (Field Types).
See Also
Concepts
Building Block: Columns and Field Types
How to: Create a Custom Field Type