cd ../blog
$ published · 1 min read

The Different Flavors of XsltListViewWebPart

A deep dive into deploying the XsltListViewWebPart in SharePoint 2010 — hardcoded list IDs, the View tag, and the minimal webpart approach.

#sharepoint#sharepoint-2010#deployment
</>

Update: I’ve released a tool that generates the elements.xml file for you — just create a webpart page and use the tool to extract the module from it. You can find the blog post about the tool here.

So yesterday I had a whole day of fun with the XsltListViewWebPart (XLVWP). In SharePoint 2010, this replaces the ListViewWebPart from SharePoint 2007.

Situation

Deploying module files that contain various web parts, always including one or more XLVWPs. Since we’d added folders to the lists, we also needed to add scope="recursive" to them.

Problems

  1. XLVWPs are not actually “deployable” — they contain hardcoded List IDs
  2. The default view is always used, so even if you set it correctly, the architecture of the XLVWP works against you

Solution: Deploying an XsltListViewWebPart

First, if you want to export an XsltListViewWebPart, you have to do it via SharePoint Designer — it’s not possible to export via the GUI.

In SharePoint Designer: go to the page → select “Save Web Part”.

You’ll get a .webpart file containing something like this:

<property name="ListName">{GUID-OF-YOUR-LIST}</property>
<property name="WebId">00000000-0000-0000-0000-000000000000</property>
<property name="XmlDefinition">
  ...url attribute with server-relative url of the list...
</property>

After reviewing the entire XML structure you’ll see three things:

  • In ListName it gives a GUID (list ID)
  • In WebId a null GUID is given
  • In XmlDefinition the url attribute is filled in with the server-relative URL of the list

The problem: this GUID is hardcoded to the specific list. If you delete and recreate the list, the ID changes and the webpart breaks with a generic error page.

Tip: append ?contents=1 to the .aspx URL to see which web part is causing issues.

Two Solutions

Option 1: Use the View Tag

Create a <View> tag and put in a minimal XsltListViewWebPart.

The <View> element specifies list view Web Parts to use on site pages. You can define properties like scope, rowlimit, etc.

Option 2: Minimal WebPart Properties

Minimize the properties in the XsltListViewWebPart. Note the property name: ListUrl.

Important: Do NOT put a / in front of Lists. This will cause an error where the web part cannot find the list.

Deployment Gotcha

Be careful when deploying the page more than once — web parts are just added without generating a new web part ID. This results in an error saying the web part with that ID already exists.

Best practice: completely remove the pages and recreate them via the elements file. Of course, any changes made to the page in the meantime will be lost.

Resources