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, this is for SharePoint 2010 in SharePoint 2007 it’s called the listviewwebpart.
Deployment of the module files that contain all kinds of webparts and always 1 or more XLVWP(s) .
But since we’ve added folders to the lists than this isn’t sufficient and we need to add “scope=recursive” to it as well.
- XLVWP are not actually “deployable” (hardcoded list ID’s)
- The default view is always used, so even if you set it correctly, the architecture of the XLVWP will work against you
This really depends on what you want to do…
Deployment of an XsltListViewWebpart
First things first, check out this post if you don’t know how to provision a webpart to a page.
Ok, now a first issue.. if you want to export a XsltListViewWebpart, you will have to do it via SharePoint Designer, it is not possible to export it via the GUI.
So fire up the old SharePoint Designer, go to the page, and select save web part.
Now you should have a .webpart file that should contain something like this:
After reviewing the entire xml structure you will see 3 things:
- in the listName it gives a guid (list id)
- in the webID property a null guid is given
- in the xmldefinition property the url attribute is being filled in with the server relative url of the list.
So this is not good, the entire xml is too much and uses a listID? Yup, it actually expects to be redeployed with a single change.. Delete the list and recreate the exact same one.. the list id will be changed.. it will not work and give you an error message.
Well happy hunting to what this could be.
you could add ?contents=1 behind the .aspx in the url, than you can see that one webpart is giving issues.
Now the solution:
There are actually 2 possible solutions:
- Either create a view tag and put in a minimal xsltlistviewwebpart like the picture below
the view tag is a special one
but if you click on the view tag hyperlink you can read “Describes a view within a module for a site definition.”.
mmmm, so no listviewwebpart stuff?
But you can define some other properties as well, like scope, rowlimit,…
- the second solution to minimize the properties being given with the xsltlistviewwebpart
Note the property name, ListUrl…
do not put an “/” in front of Lists, this will create an issue with the webpart that it cannot find the list.
Be careful when deploying the page more than 1 time, the webparts are just being added without rendering a new webpart ID. This will result in an error message saying that the webpart with the ID already exists. Best practice is to completely remove the pages and recreate them again via the elements file. Of course all changes made to the page in the meanwhile will be lost than.
I’ve created a codeplex solution for the generation of the webpart pages into a module (elements.xml) file. you can find it here
- MSDN: XsltListViewWebPart and Custom List Views
- Via SharePoint Designer..
- XsltListViewWebpart, several Xslt tips
And a teaser for one of the next blog posts…
In the last resource link a sentence stands out in the blog:
The short story of a lot of tries is: it does not work. Yes you can change the XmlDefinition property, but the XsltListViewWebPart does not use it after you have changed it.