javascript.jpg

Computed Fields in SP 2010

Computed fields in SharePoint are often confused with Calculated Fields. Calculated fields are useful for taking other fields values within the same record and combining them in some way into another field. Computed fields, on the other hand, are most useful for render time. If you need to have special JavaScript, for example, you cannot use a Calculated field.

Creating a computed field in SP2010 requires two steps:

  1. Creating the field schema.
  2. Creating the field XSL.

Creating the Field Schema

This can be done by adding the field to the schema.xml file (if you are defining the list) or via the API by calling SPList.Fields.AddFieldAsXML(myXml).

The field schema should look like the following:

<Field ID="{6ddf785c-bce5-421c-95ba-c984b73993ed}" Name="SubmissionTitleLink" DisplayName="Title" TextOnly="TRUE" ReadOnly="TRUE" Type="Computed" Sortable="FALSE" Filterable="FALSE" ClassInfo="Icon" AuthoringInfo="(link to view item)" SourceID="http://schemas.microsoft.com/sharepoint/v3" StaticName="SubmissionTitle" FromBaseType="TRUE">
  <FieldRefs>
    <FieldRef Name="ID"/>
    <FieldRef Name="Title"/>
  </FieldRefs>
</Field>

To create the ID, just generate your own GUID and set the Name, DisplayName, and StaticName to the appropriate values(s). You can also set the AuthoringInfo to whatever makes sense for you.

The FieldRef entries are required for any field values that you need to consume when you render. A normal one might be <FieldRef Name="Title" />.

You might be tempted to add a <DisplayPattern> to your field schema. Don’t bother because it is ignored in SP2010. This was used in SP2007, but now SP2010 uses the field XSL discussed below (see also: http://stackoverflow.com/questions/2368016/problem-with-displaypattern-in-sharepoint-2010).

Creating the Field XSL

This is where you provide the rendering logic for your field. This will be used by the XSLTListViewWebPart (list views). You need to create a file and put it in 14\TEMPLATE\LAYOUTS\XSL. The file name should be fldtypes_*.xsl (e.g., fldtypes_mycompany_myproject.xsl). Here is an example:

<xsl:template match="FieldRef[@ID='6ddf785c-bce5-421c-95ba-c984b73993ed']" mode="Computed_body">
  <xsl:param name="thisNode" select="."/>
  <a href="#">
    <xsl:attribute name="onclick">
      <xsl:text>viewViaJavaScript(</xsl:text>
      <xsl:value-of select="$thisNode/@ID"/>
      <xsl:text>); return false;</xsl:text>
    </xsl:attribute>
    <xsl:value-of select="$thisNode/@Title"/>
  </a>
</xsl:template>

In this case we use ID and Title from the list to provide a link with a JavaScript onclick event. The field defined in the first section had to have the ID and Title fields in the <FieldRefs> section to make these available. Instead of matching on ID, you can match on Name. However, since this XSL is global across all lists, using the ID is probably a better choice.

Unfortunately, it would be nice to be able to see the XML available to us using something like <xsl:copy-of select="*"/> or <xsl:copy-of select="$thisNode"/> (similar to how it is done here: http://msdn.microsoft.com/en-us/library/ms546985.aspx), but this did not appear to help.

Note that any time you change your field XSL you’ll need to restart your web application pool to clear the old one from cache.

References:

Kirk LiemohnComputed Fields in SP 2010
Share this post

Join the conversation

Related Posts