I think everybody knows about Data View (or Data Form) Web Part (DVWP) but there are a very few who know its range of capabilities. A developer who is more comfortable with Visual Studio and has access to servers, tend to resolve non Out of the Box problems in SharePoint with .NET custom web parts. I have recently explored DVWP’s capabilities and even though I am a hardcore developer J, I am in love with DVWPs. These web parts can only be created using SharePoint Designer (SPD). Now that SharePoint Designer 2007 is free, this opens the door to a lot more people being able to create these web parts, without any need of server access or deployment.
DVWPs are able to retrieve data from various data sources in the form of XML even if the data itself in its original form is not XML. eXtensible Stylesheet Language Transformations (XSLT) can be used to change the appearance of returned data.
You can find numerous articles over internet on introduction of DVWPs and how to use them. Instead of reinventing the whole wheel, I am listing down few articles which I find good to start with.
Articles by Laura Rogers: Data View Web Parts Basics: http://www.sharepoint911.com/blogs/laura/Lists/Posts/Post.aspx?List=676af157-7d96-4e15-a987-54b8a3e4d948&ID=23
Articles by Marc D. Anderson: Understand XSL tags in Data View Web Parts:
SharePoint Data View Web Part Extension Functions in the ddwrt Namespace: http://msdn.microsoft.com/en-us/library/dd583143(office.11).aspx
SharePoint Designer slowness
We use SharePoint Designer (SPD) for creating master page and page layouts. So, we don’t observe (or rather don’t mind) the slowness of SPD. Once you frequently start dealing with DVWPs, you will see extensive use of SPD and hence the slowness of SPD will start getting in your nerves. Although, there are no alternative or a complete fix to resolve this problem, there are a few best practices you can follow to make your life easier. Read my post about SharePoint Designer is very slow? Follow these practices to make your life easier
Few Best Practices
Apart from these, I am listing down few best practices which are not mentioned in other articles:
1 Bring only those columns which are necessary: When you drop a DVWP on the page, it brings all columns from the list/library under <DataFields> tag. However, you don’t use all the columns as required. For example @Author,Created By;@Editor,Modified By;@_UIVersionString,Version;@Attachments,Attachments;@File_x0020_Type,File Type; are hardly used. When the page loads in the browser, it tries to render all the columns listed under <DataFields> tag. You can improve the performance of your DVWP and hence the page by deleting those columns which are not used either in your CAML statement or XSL.
2 Replacing ListID with ListName: If you are developing DVWPs in one environment and porting them to a different environment on frequent basis, then replace the occurrences of ListID with ListName. When you drop a data view on the page, it refers the list by ListID (GUID). This is useful in the case when you change the name of the list. Since, changing the list name don’t affect GUID, the webpart works fine. But in the scenario when you move this web part to different environment (e.g. from stage to production), where a list with same name exists, it breaks DVWP. So in these cases, change the word ListID to ListName and change the GUID value to the real list name.
After, you get well versed with DVWPs; you can then make an intelligent decision on whether to use DVWP or .NET custom web part. As a rule of the thumb, try to approach a solution using DVWP. Since, this does not require any deployment; it is always easy and quick to make future updates. However, DVWP can be slow sometimes considering the fact that it fetches data using web services. Also, there are a couple of limitations. Such as performance and UI issues with linked data sources and data view connected web parts. Develop .NET custom web parts in those scenarios.