Guidance for XslLink property with the XsltListViewWebPart

  • Article

The XsltListViewWebPart as well as the DataFormWebPart are having the same base class BaseXsltDataWebPart  and work quite similar. While for the DataFormWebPart it is OK and intended to use the Xsl and XslLink property, in current SharePoint versions the it is strongly recommended not to use the Xsl and XslLink properties with the XsltListViewWebPart. Both these properties exist as they are inherited from DataFormWebPart

In fact the Xsl property is can’t be edited in the Web Browser as it is explicitly missing from GUI.

The reason to limit the Xsl customization for the XsltListViewWebPart is that this Web Part – that is used heavily over all different places – was optimized in terms of performance. Not only the Web Part itself but also the OOB XSL files (like main.xsl in the layouts folder) were optimized to perform well in the Browser. This is also the reason why the compiled Xsl is written into the Web Part cache – to optimize performance & that's why it is recommended not to make a change in the XsltListViewWebPart.

For the reason to have a custom look and feel a different Web Part exists that should be used instead   The DataFormWebPart. Basically DataFormWebPart would work as the compiled XSL is cached differently, but using the DataFormWebPart would mean you would need to manually replace each existing XsltListViewWebPart by touching the WebPartPage with SharePoint Designer.

To insert a DataFormWebPart in SharePoint Designer you would have to choose in the SharePoint Designer Editor “Insert – Data View – Empty Data View” click at “Click here to select a data source” then select the Source List and finally select in the Dropdown List at the right “Insert selected fields as…” the value “Multiple Item View”. After that you save the changes and can now continue the modification either in SharePoint Designer or the Web Browser interface.

Speaking about different alternatives for the XsltListViewWebPart,

To work around this behavior you need to stop using the XslLink property of the Web Part, as the caching is more or less bound to this property & this can impact the performance of a page on which the web-part exists . There exist other alternatives to let the XsltListViewWebPart use your XSL Transform.

You would need to specify some inline XSL like this:

<Xsl>

<xsl:stylesheet <!-- namespaces removed to be better readable--> >

<xsl:include href="/SiteAssets/Custom.xsl"/>

</xsl:stylesheet>

</Xsl>

The Xsl property works here as it does not need to be cached – the XsltListViewWebPart treats the content of the Xsl property already as compiled Xsl. Again You need to use SharePoint Designer to set this property .

Workaround 2: Create a custom view per List and set the XslLink property on the View rather than the WebPart as you currently do, however you would need to place your XSL file in the default “_layouts/xsl” folder

Sample Code : Please note:

This source code is freeware and is provided on an "as is" basis without warranties of any kind, whether express or implied, including without limitation warranties that the code is free of defect, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the code is with the end user.

Function CopyViewAndSetXslLink

{

param($Url, $ListName, $ViewName, $NewViewName, $XslFileName)

$web = Get-SPWeb $Url

$list = $web.Lists[$ListName]

$view = $list.Views[$ViewName]

$view = $view.Clone($NewViewName, $view.RowLimit, $view.Paged, $false)

$view.XslLink = $XslFileName

$view.Update()

}

CopyViewAndSetXslLink -Url "https://sp"

-ListName "Shared Documents"

-ViewName "All Items"

-NewViewName "Xsl"

-XslFileName "Custom.xsl"

In this example for the Document Library “Shared Documents” the existing view “All Documents” is duplicated and saved as custom view with the name “Xsl”. For this new view the XslLink property is set to “Custom.xsl” that is supposed to be stored in “_layouts/xsl” folder.

This view “Xsl” can now be selected in the corresponding XsltListViewWebParts that are bound to this List /Document Library .

The reason the caching is here no issue is because of the fact the XSL file is places in the Layouts folder. Files in this folder are cached centrally as those are supposed to be used by Views. As they are cached already neither the View nor the Web Part have to cache them.

So by following this approach you should get a slight performance increase as the XSL file is once cached centrally while in your current approach it is cached once per single Web Part.

 

Post By:Rajan Kapoor [MSFT]

 

 

Disclaimer

=========

By using the following materials or sample code you agree to be bound by the license terms below and the Microsoft Partner Program Agreement the terms of which are incorporated herein by this reference. These license terms are an agreement between Microsoft Corporation (or, if applicable based on where you are located, one of its affiliates) and you. Any materials (other than sample code) we provide to you are for your internal use only. Any sample code is provided for the purpose of illustration only and is not intended to be used in a production environment. We grant you a nonexclusive, royalty-free right to use and modify the sample code and to reproduce and distribute the object code form of the sample code, provided that you agree:  to not use Microsoft's name, logo, or trademarks to market your software product in which the sample code is embedded; (ii) to include a valid copyright notice on your software product in which the sample code is embedded; (iii) to provide on behalf of and for the benefit of your subcontractors a disclaimer of warranties, exclusion of liability for indirect and consequential damages and a reasonable limitation of liability; and (iv) to indemnify, hold harmless, and defend Microsoft, its affiliates and suppliers from and against any third party claims or lawsuits, including attorneys' fees, that arise or result from the use or distribution of the sample.