XsltListViewWebPart and Custom List Views
Applies to: SharePoint Foundation 2010
The new XsltListViewWebPart class in Microsoft SharePoint Foundation 2010 derives from the XSL-based DataFormWebPart class. It replaces the ListViewWebPart class as the default view type in list views, although it generates equivalent HTML for the same view settings. Similarly, the XsltListFormWebPart class replaces the ListFormWebPart class as the default view type in list item forms. Unlike the ListViewWebPart class, the XsltListViewWebPart class uses XSLT transforms to define HTML rendering, instead of using the HTML rendering elements of the View schema in Collaborative Application Markup Language (CAML). The XSLT files that are applied through the XsltListViewWebPart class are cached on each front-end web server, and they support all languages, instead of only one language per XSLT file. This provides greater scalability in SharePoint Foundation because each XSLT file is compiled and consumes a small amount of server resources. In addition, the XsltListViewWebPart class uses ASP.NET AJAX to perform ad-hoc filtering, instead of the IFrame approach that is used in CAML, and the output of the XSLT transforms that are applied through the XsltListViewWebPart class is XHTML. Whether they are in list views or in item forms, the XsltListViewWebPart class and XSLT templates provide the best way to meet ASP.NET AJAX, XHTML, and external data requirements for SharePoint Foundation views, while converging on one customizable view technology.
You can customize views in the browser through the SharePoint Foundation user interface, in Microsoft SharePoint Designer 2010, or in Microsoft Visual Studio 2010. You can implement custom XSLT in the XsltListViewWebPart class to define custom list views. The custom XSLT can just override certain templates in the default XSLT files, or it can completely replace them. You can deploy the custom XSLT files to either the %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES folder, or to the %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS folder. You can specify XSLT-based list views in the <Views> section of the Schema.xml file for a list definition by using the XslLink element in a view definition. For information about how SharePoint Foundation uses XSLT templates, and about the default XSLT files that are installed, see Overview of XSLT List View Rendering System.
XsltListViewWebPart generates an HTML view of a list from XML data that is obtained by running a query that is defined in the Query element of the XmlDefinition property of the Web Part. In addition to the query, the XmlDefinition property contains descriptions of various view attributes, including which underlying view style to use (for example, Basic Table or Boxed), which fields to display in the view, the number of data rows to display in a single page, and other settings that are specified in the Schema.xml file of the list. The list definition in the Schema.xml file serves as the source node tree for the XSLT processor, which parses the schema to create the result tree that is contained in the XmlDefinition property.
The syntax of the XmlDefinition property is based on the SharePoint FoundationListViewXml property of the ListViewWebPart class. The XsltListViewWebPart class uses the query description in the XmlDefinition property to create an SPDataSource control and retrieves data as XML. The Web Part then runs an XSLT transform on the XML data, using parameters that include the list schema and the XmlDefinition view description. The XSLT is schema-agnostic, which means that it adapts to the schema of the referenced list. You can add or remove fields, or change their type, and the XSLT still renders the view correctly. The XSLT adapts to view settings that are specified in the XmlDefinition property, such as for the view style. It uses <xsl:apply-templates> to iterate over each row of data and each view field in the manner that is defined by the view style and list schema. The matching XSLT templates generate HTML output, which is then sent to the browser. For information about how dsQueryResponse XML is used in XSLT list views to render the XML data, see Examples of Input and Result Node Trees in XSLT Transformations.
When you use the SharePoint Foundation user interface to modify a view in the browser, it changes the declarative settings of the XmlDefinition property of the Web Part within its Web Part zone. This causes the Web Part to generate HTML that is equivalent to the SharePoint FoundationListViewWebPart class. You can further customize the Web Part in SharePoint Designer, which does not require a conversion step, and does not prevent you from making additional changes in the browser. The XSLT for the Web Part remains unchanged and cached in a read-only location on the front-end web server, and it is reused by all XsltListViewWebPart controls. Changes that you make in SharePoint Designer override the cached XSLT and are written into the Xsl property of the Web Part. SharePoint Foundation takes advantage of the import precedence rules and template-matching behavior in XSLT to override only specified templates. This enables you to make fine-grained changes to the HTML that is generated, without affecting the front-end XSLT files or copying the changes into the Web Part. Only the overridden templates are saved into the Xsl property of the Web Part.
Derivation of XsltListViewWebPart
The XsltListViewWebPart class inherits from the DataFormWebPart class according to the following hierarchy:
Inherited Properties
The XsltListViewWebPart class inherits many members from the DataFormWebPart class, including the members that are listed in the following table. The table indicates whether the XML equivalent for each property is persisted as an element or an attribute.
Property Name |
XML Persistence |
Description |
|---|---|---|
Element |
Optional. Specifies a DataSourceCollection object that represents IDataSource interfaces. Normally, the XmlDefinition property is used instead to synthesize a data source control (SPDataSource) when the view is rendered. An exception is thrown if this property is present in the XsltListViewWebPart. |
|
Attribute |
Contains a list reference that uses the localized display name, such as Announcements. |
|
Attribute |
Contains a list reference in {GUID} format with the same syntax as the equivalent ListViewWebPart attribute. |
|
Attribute |
Contains a list reference in URL format that is relative to the website, such as Lists/Announcements. |
|
Element |
Contains a valid View element that has the same syntax that was supported by the SharePoint FoundationListViewWebPart class, minus the CAML rendering tags (see XMLDefinition and CAML View Schema). |
|
Attribute |
Specifies a URL reference to an XML file that defines the contents of the XmlDefinition property. |
|
Element |
Optional. Contains an inline style sheet. |
|
Element |
Optional. Contains a URL that specifies an XSLT file to use for transformation. |
One of the List* properties (ListName, ListUrl, or ListDisplayName) must be present and must specify a reference to a valid list. If more than one property is present, the order of evaluation is ListName, then ListUrl, and then ListDisplayName.
If one of the XmlDefinition* properties (XmlDefinition or XmlDefinitionLink) is present, it must result in a valid View element. Otherwise, the view definition from the default view of the list is used instead (in other words, from Schema.xml). If more than one property is present, the order of evaluation is XmlDefinitionLink, and then XmlDefinition.
As with the Xsl property and the XslLink property of DataFormWebPart class, the order of evaluation is first XslLink, and then XSL. If neither XSL nor XslLink is specified, the XSLT file that is referenced by the View element in Schema.xml is used for the transformation. The presence of an XSL or XslLink property indicates that the view was customized in SharePoint Designer to override the default cached and uncustomized XSLT. The XSL property is never modified through the SharePoint Foundation user interface, but only through SharePoint Designer when explicit formatting actions are taken (as opposed to the query modification). For example, conditional formatting in SharePoint Designer requires you to update the contents of XSL, but adding or removing columns does not.
The GetDataSource() method of the XsltListViewWebPart class overrides the GetDataSource() method of the DataFormWebPart class. The XsltListViewWebPart class first resolves the list reference, and then creates a data source control (SPDataSource) based on the contents of the XmlDefinition property.
See Also
Concepts
Overview of XSLT List View Rendering System
Examples of Input and Result Node Trees in XSLT Transformations
XMLDefinition and CAML View Schema