After working with the XSLT List View Web Part for a good while now I’ve discovered some great features and a few annoying niggles or bugs. Whilst I’ll continue to post new finds and interesting techniques, I thought it worthwhile gathering the list of bugs together into a series – as I believe they’re something you should be aware of if planning on using the XLV extensively in your solution (and why wouldn’t you!).
The series will consist of:
- View settings lost on saved XSLT List View Web Part (this post!)
- Content type enabled list XLV can’t be added to sites
- XSL Link Property and the ECB Menu (published in May 2011)
- Multiple web front ends, conflicts and the XLV
- Unable to use folders with cross-site XLV
The Bug
Having configured your list view exactly how you need; possibly having spent a while adding/ removing columns, choosing sort orders and filters etc you now decide that you want to re-use all your effort by having exactly the same XLV on a different page, or even site.
The first step is to export your web part. This can be done via SharePoint Designer 2010 or by the XLV export/ import method that I’ve previously posted. You now try and add your web part to a page using the browser, i.e. not using SharePoint Designer.
Immediately after adding the web part everything is looking great – the list view is displayed exactly as it was on wherever you exported it from. Now you hit Save or Check In… and the XLV reverts to the default view on the list! Your carefully configured view has just been lost – and that’s the bug 
Example
Here’s an example of this in action. First I add a simple custom list to a page, modify the view and, just because we can, jump into SPD 2010 to add some custom formatting:
I now use SharePoint Designer to export the web part and add it to the gallery:
Now, I go back to the browser, create a new page and add the web part. There’s my nicely configured view…
But now I hit save on the page and BOOM there goes my view back to the default on the list:
So my view has been changed, including my sort order and columns chosen to display – but strangely my custom formatting is still there! What is going on…
Explanation
I lack the skills to step through the underlying code of what exactly happens when the imported web part is attempted to be saved back to the page – however I think we can infer a few things from the behaviour and by inspecting the web part properties (of an exported XLV).
Firstly – why is the custom formatting still there, plus the web part title, chrome settings etc etc. Well I think we can confidentially assume that those particular properties of the web part are persisting. Looking at the .webpart file of an XLV we can find the corresponding properties and their values.
So where are the view settings defined in the properties. Well, I can only assume that this is in the property called XmlDefinition. Looking at this property we can see that it defines the CAML necessary for the view – plus it seems to reference an actual view on the list itself…
I found this excellent post by Stefan Stanev who goes into a great amount of detail explaining that when you add a list view web part to a page there is actually a view created on the list itself! The view is set to hidden and so you never know it’s there – but it’s fascinating that it exists.
Now we think we know that the XmlDefinition property is where an XLV gets its view settings from we should be able to use this to give an XLV a particular view which can be imported again and again right? Well, you’d think so… but unfortunately I haven’t been able to get it to work yet.
It feels like I’m tantalising close to working this out – but then hey, why should I have to? I can add an exported XLV into the gallery using a supported tool like SPD. When adding to a page this then appears to take on the view settings, only to have them lost on saving a page. That sounds like a bug to me!
Workarounds
The (only slightly) good news is that you can use SharePoint Designer to add a web part to the page and it will remember the view settings! Obviously there is something going on behind the scenes different to what happens when adding through the browser.
Another option is to set the default view on the list to be the same as your web part view – and then this will be the view used when adding the web part.
[This was done on SP2010 RMT – I haven’t looked at SP1 yet]