RenderPattern Element (Field Types)
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.
Defines the actual Collaborative Application Markup Language (CAML), HTML, and script that Windows SharePoint Services 3.0 can use, as an alternative to a rendering template control (.ascx file), to render the field type in the UI. Also, in list views, this element renders the column headers, based on the selected field type.
<RenderPattern Name="Text">
</RenderPattern>
Attributes
Attribute |
Description |
|---|---|
Name |
Required String. Represents the name of the render pattern you are defining in this RenderPattern element. Valid values are
|
Child Elements
None explicitly defined, but this element is a container of CAML markup from the View Schema |
Parent Elements
Remarks
Inheritance of RenderPatterns
If a RenderPattern with a particular Name value is not provided for a field type, the field type inherits the RenderPattern with that name from its parent field type.
HeaderPattern
All field types must have a HeaderPattern type of RenderPattern element, either directly or by inheritance, because there is no alternate system for rendering column headers. The markup in a HeaderPattern can be quite simple when the field type is cannot be sorted or filtered. However, if the field type can be sorted or filtered, then the markup can become quite complex because the header serves not just as the title for the column but also as a drop-down menu control for sorting and filtering. Moreover, because the ability to be sorted and filtered can be disabled for particular columns (even when the field type the column is based on supports them) the markup must use Switch elements to test whether sorting or filtering is enabled for the column. See C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\FLDTYPES.XML for examples.
DisplayPattern
A field type usually must have a DisplayPattern type of RenderPattern element (by inheritance, if not directly) so that the field can be rendered in each row of a list view. The DisplayPattern type of RenderPattern is also used to render most fields in Display mode; such as on the Display (list item) page. Alternatively, a field can be rendered in Display mode (but not on list views) by means of a rendering control (.ascx file). However, the main advantage of using a rendering control is to provide data validation and processing, and those functions are not needed when the data (valid or not) is merely being displayed instead of created or edited. For that reason, none of the field types that ship with Windows SharePoint Services 3.0 use a rendering control rather than a DisplayPattern type of RenderPattern element to render the field in Display mode. Probably, all of the custom field types that you create will use a DisplayPattern for Display mode also.
Note
Two field types that ship with Windows SharePoint Services 3.0 do not have a DisplayPattern type of RenderPattern in FLDTYPES.XML: (1) ContentTypeId fields are never visible. (2) Computed fields are rendered on list views and in Display mode by a DisplayPattern element in their Field elements within the schema.xml of each list on which they appear.
NewPattern and EditPattern
The NewPattern and EditPattern types of RenderPattern are used to render a field in New mode and Edit mode, respectively, when the field does not require significant data processing or data validation when a list item containing the field is being created or edited. Free-form Note fields, for example, cannot be validated because any text is a valid value. Similarly, Choice fields and Lookup fields, by definition, limit the user's choices to only valid values. Other fields, such as Currency and DateTime, need only minimal validation that can be coded in script.
Custom fields you create that inherit from any of these types may, however, require more substantial processing. If so, use a rendering control to render the field. Usually, in fact, the reason you need a custom field is precisely because none of the fields that ship with Windows SharePoint Services 3.0 contain the data validation that you need.
See C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\FLDTYPES.XML for examples of NewPattern and EditPattern types of RenderPatterns.
RenderPatterns for MultiColumn-Derived Custom Field Types
In your RenderPattern markup for a custom MultiColumn field, use the SubcolumnNumber attribute of a Column element to specify an individual column in a multicolumn field type. For more information about multicolumn field types, see Custom Multicolumn Field Classes.
Example
The following example defines a display rendering pattern for a custom field type that inherits from the MultiColumn type. The field is used to store American addresses. The first subcolumn stores the street address. This is followed by an HTML line break. The next subcolumn stores the city name and it is followed by a comma and a space. The third subcolumn stores the state and, following a space, the last subcolumn stores the postal code.
<RenderPattern Name="DisplayPattern">
<Switch>
<Expr><Column/></Expr>
<Case Value="">
</Case>
<Default>
<Column SubColumnNumber="0" HTMLEncode="TRUE"/>
<HTML><![CDATA[<BR>]]></HTML>
<Column SubColumnNumber="1" HTMLEncode="TRUE"/>
<HTML><![CDATA[, ]]></HTML>
<Column SubColumnNumber="2" HTMLEncode="TRUE"/>
<HTML><![CDATA[ ]]></HTML>
<Column SubColumnNumber="3" HTMLEncode="TRUE"/>
</Default>
</Switch>
</RenderPattern>
See Also
Tasks
Walkthrough: Creating a Custom Field Type