I have been customizing dataview web-parts for years-for SharePoint they are extremely handy for displaying list data and given you can convert to XSLT view and hack away at the XSLT they definitely provide a level of customization out-of-the-box especially using SharePoint Designer, aggregated datasources, etc. Even developed a content rating and commenting system all just using dataview web-parts, customized XSLT and linked datasources. Check out previous post last year Implementing Content Ratings for Sharepoint via site template Part 1 and Part II step-by-step for just on example.
But there is a darkside to the trusty DVWP…the list ids are hard-coded into the datasource provider which reduces the portability from one site page to another. You can mitigate somewhat by swapping out the listids for listnames but that could create conflicts since you have two lists with the same name in SharePoint (hence the listid). You can also centralize the XSLT by storing as a file and then referencing from the dataview web-part settings in SP Designer but still no matter how you look at it things always get messy. I am convinced this is one of the main roadblocks to making it easy for site editors to make the content dispersed throughout the SharePoint more discoverable. Blogs are a great example-have you ever tried to develop a customized view of a SharePoint blog or post and host on another page? How about another page in another site collection? It’s possible but a ton of work for something that should be easy.
Recently I have ditched the DVWP in favor using Silverlight to consume/display list data where consuming list data in a customized user-experience is required. Developed a generic Silverlight web-part that users can configure via the web-part properties pane easy enough. Plus can be exported/imported from site pages and uploaded into the web part gallery for everyone’s use. Do that with a customized dataview web-part.
Advantages of this approach:
- Can be added to any site page on any site collection easily by the user without a developer or SharePoint Designer involved.
- Can be easily deployed on our customer’s SharePoint sites and do not require a substantial effort to migrate to new hardware.
- A more rich UI is possible using Silverlight and development is simplified using Visual Studio and C#.
- The project files (.xap) developed in Silverlight are stored in standard SharePoint libraries and can be updated without the need for IT to be involved.
I can hear the comments coming…what if I can’t deploy "real" webparts since I don’t have administrative rights on the server or our customers SharePoint environment is locked-down? I feel your pain, been there, done that. Here is the answer-drop your Silverlight application .xap file into a SharePoint document library along with the html test page and simply reference via an inframe in another famous web-part the Content Editor Web-Part. Another web-part with it’s own set of pros/cons for sure but handy in this case for displaying your Silverlight application on a site page without having to develop/install custom web-parts.
Recently posted several examples of how to pull SharePoint list data into Silverlight in variety of ways and even the source code so check it out-one more tool to add to your SharePoint arsenal.