RenderPattern Element (Field Types)
This topic describes markup that was used in a now obsolete method of rendering custom fields types on list views and on the Display, Edit, and New forms. It is provided solely to assist persons who are debugging a custom field type that was originally developed against an earlier version of SharePoint Foundation. For information about the recommended methods, see Field Rendering Templates and Patterns of Custom Field Rendering.
Custom fields whose rendering is defined with RenderPattern markup still render properly on forms. However, SharePoint Foundation, by default, uses XSLT stylesheets to render fields on list views, even for legacy custom fields whose list view rendering is defined with a RenderPattern. To enable the rendering of such a field, a <Field Name="CAMLRendering">TRUE</Field> element must be added to the containing FieldTypes element in the field type definition file (fldtype*.xml).
RenderPattern defines the actual Collaborative Application Markup Language (CAML), HTML, and script that SharePoint Foundation can use to render the field type in the UI. Also, in list views, this element renders the column headers, based on the selected field type.
Required String. Represents the name of the render pattern you are defining in this RenderPattern element.
Valid values are
None explicitly defined, but this element is a container of CAML markup from the View Schema
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.
If CAML rendering is enabled (see above), the field type must have a HeaderPattern type of RenderPattern element, either directly or by inheritance, or the column header of the field on list views does not render. The markup in a HeaderPattern can be quite simple when the field type 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 %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\XML\FLDTYPES.XML for examples.
If CAML rendering is enabled (see above), a field type must have a DisplayPattern type of RenderPattern element (by inheritance, if not directly) so that the field can be rendered on list views. This is not necessary to render the field in Display mode, such as on the Display (list item) page, because, a field can also be rendered in Display mode by means of a rendering control (.ascx file). None of the legacy field types that ship with SharePoint Foundation use a rendering control rather than a DisplayPattern type of RenderPattern element to render the field in Display mode.
The DisplayPattern type of RenderPattern can also be used to render the field in each row of a list view. By default, SharePoint Foundation uses XSLT markup in a fldtypes*.xsl file located in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\XSL to render fields on list views. But the fldtypes*.xml file in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\XML is checked for the presence of <Field Name="CAMLRendering">TRUE</Field> in the containing FieldTypes element for the field. If it is present, the DisplayPattern is used to render the field on list views.
Two legacy field types that ship with SharePoint Foundation 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 were used to render a field in New mode and Edit mode, respectively, when the field did not require significant data processing or data validation when a list item containing the field was 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.
See %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\XML\FLDTYPES.XML for examples of NewPattern and EditPattern types of RenderPatterns.
RenderPatterns for MultiColumn-Derived Custom Field Types
In the RenderPattern markup for a custom MultiColumn field, the SubcolumnNumber attribute of a Column element is used to specify an individual column in a multicolumn field type. For more information about multicolumn field types, see Custom Multicolumn Field Classes.
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>