The Good, the Bad and the DataViewWebPart

Tags: SharePoint

Sunday, May 1, 2005 8:46:00 AM

Been wrestling lately with Sharepoint's DataViewWebPart (DVWP, from now on). I'm still pretty ambivalent about it.

Pros:

  • Easy to set up  - just add a list as a web-part, open it in Frontpage, right-click and Convert to XSLT.
  • Very customizable. I like XSLT. I can tweak it any way I want, generating custom rendering for my fields that would otherwise require me to write a custom web-part or a custom FieldType, which is too much hassle.
  • Presentation only. All the data-access logic is taken care of behind the scenes, and I have all the properties of my list items as XSLT parameters to play with as I choose.

Cons:

  • Not Portable. If I build a menu off of a list (as detailed here, excellent article), that DVWP is linked to the list's GUID. If I now want to copy that DVWP to a different subsite, I have to edit the hardcoded GUID or start messing with passing GUIDs as parameters and whatnot.
  • Messy, messy, messy. Tweaking unformatted XSLT in FP2003's Code view is a big, big pain - and a slip of the keyboard can make the DVWP unrenderable with no real explanation where you screwed up.
  • Maintainability is hell. Code is embedded directly in the page. If I want that DVWP on every page in my site (for the menu), I have to add it to every page manually, and update every change manually - even if I export it to a DWP file and just import to each page, I still need to update manually when things change. Anyway, it's a break from the content/presentation split that ASP.NET is pushing.

Right now I've given up on the DVWP approach and simply wrote a web-part in C# - it's portable, integrates well with my source-control-provider-of-choice, and the distinctions between unit of functionality and the page it resides in is clear.

Anyone have any supporting/opposing POVs? Any hints or tricks that make DVWPs more useful outside of the single-site scope?

11 Comments

  • Serge van den Oever [Macaw] said

    I also thought DVWP's were difficult to deploy, GUID rewriting etc. But if you use DVWP's in for example a list, save this list as template, the DVWP GUID's are rewritten correctly on instatiation of the template. See the MacawDiscussionBoard template for an example (see my weblog). Still the problem of code duplication, no single point of update...

    It is a pity that the xsl:include is blocked;-)

  • Avner Kashtan said

    I've tried to take out the whole XSL chunk and replace it with an XSLLink property pointing to a single XSLT file (in the _layouts directory, in my case).
    For some reason, it displayed fine in Frontpage, but not in the browser.

  • Craig Box said

    Hear hear!

    From my experience - I totally agree - steer clear of the DVWP.. good in theory/prototype.. bad in portability - great to get some funky CAML/XSLT though!

    I ended up doing the same - creating a custom webpart for the end users (who don't know XSL) - to select the list then select a style - it allows for a single point of update.

  • Bil Simser said

    I agree it's the good, bad, and ugly of SharePoint. Everyone boasts about how fantastic it is to "visually design XML" with it that's great but as you said portability and maintainability is the pits.

    The one option is to create a custom DVWP container Web Part. It would internally create a DVWP (which you can programatically) and say have two properties, one for the name of the list (from which you can get the Guid when it's set) and the other would be the XML for the DVWP. Might work. Another option is to build the DVWPs in FP then export them and load them using the custom web part.

    All in all, nice on the surface and powerful, but only if you have static sites.

  • Anon said

    This post is late, but worthwhile as google ranks this article high. I spent 3 hrs on MS support to find out that in WSS 3.0 if you put curly braces around the GUIDs in the DataFormWebPart(DFWP) xml in sharepoint designer, when you deploy the template, the DFWP will work. Assuming your DFWP points to a list in the template. Dunno if it also might work in the DVWP and/or WSS 2.0.

  • Murlidhar Chawhan said

    i have a query regarding dataviewwebpart, i have a list which have a column "ID" this ID may include 1,1,2,2,2,3,3... now if user want to see records of ID 1 he can filter by passing paramenter as 1, Now if my user wants to filter for multiple value how can we pass parameter if i have created custom wepart for provider and default dataview webpart as my consumer. plz let me know the solution, since last one week iam trying to find the solution but no clue. mail me @ murlidharc@intelligroup.com appreciate your immediate response,

  • Scott said

    Anon, I can't find the Microsoft information on putting curly braces around the GUIDs. Can you share what you ahve learned? I can be reached at scott.anderson@sts.aecom.com Thanks, Scott

  • Roy Higgs said

    If you need to filter the web part then the ListName parameter is required and unfortunately the ListName parameter (at the DataFormWebPart level) is the GUID of the list and not the actual list name. So, at this point, I can't find a way to get a portable DFWP if I need to filter it.

Comments have been disabled for this content.