Successor and much more powerful webpart than Dataform or ListViewWebpart provided in Sharepoint 2010, yes, that’s true.
As mentioned in msdn, it handles view rendering for lists which can be document libraries as well as announcements. As the name suggests, it uses a XSLT i.e transforms for Html rendering. Xml data obtained as per Query and XmlDefinition, explained later, is converted into html using Xslt. It, by default, applies styles [ViewStyles] as provided by Sharepoint.
It provides an option to enable column filtering, sorting, Paging and AJAX as well. Yes, filtering, sorting, Paging can be done async, without whole page refresh using AJAX option.
What’s more? You can even define your own custom xsl defining styles, rendering and you have a data rendered the way you want. Custom xslt can override default templates and thus has a power to completely replace default XSLTs which is rarely needed.
For e.g. Dates to be shown in a particular format or you want to specify custom header names rather than display names defined in a list definition or a view.
Isn’t it powerful from what we had earlier?
Why am i writing this?
In my project, i had a requirement to show latest 5 documents with a More… button at the bottom in a page which had other data as well. It should support sorting, filtering but without paging. And most importantly, to show list data which exists in a different site collection.
Surely this is achievable by writing a custom visual web part and a backend code but how much time does this require? If you are following a layered approach and are following a well-defined architecture :), which you will be as a good coder, it can take a lot of time with a filtering, sorting support. And what if Client demands for Paging later. This usually happens in Agile methodology. Plus why to forget a testing?
This is where XsltListView webpart can be handy, inbuilt webpart, already test proven, just set few properties as per your requirements and you are good to go.
What to set, when, why? If you want to use this webpart and you don’t have knowledge how to use it, I pray to God.
You have now 2 options:
- Either spend a lot of time yourself, exploring this XsltListViewWebpart, or
- Refer to this blog :). If not 100% , it will definitely save more than 75% of your efforts in fiddling around
How to use?
Following are the few properties which must be considered when using this webpart:
- ListId, ListName
- ViewGuid – (Because of this and SPD, i spent a sleepless night)
- RenderContext of a toolbar [Reflection help is needed to set it, another factor for sleepless night :)]
- XmlDefinition, XmlDefinitionLink
- Xsl, XslLink
- AllowPaging, PageSize
- DisplayName, DisplayTitle
You can either make use of SharepoingDesigner (SPD) or your skill 🙂 to define XsltListViewWebPart definition declaratively.
Continue reading XSLTListViewWebpart in Sharepoint 2010 Uncovered