Custom List Views and WSS 4.0′s XSLT-based List View

Posted on Posted in SharePoint 2010

Some of us have known about this for a while but we’ve been unable to talk about it until now – Microsoft released the following article two days ago: The CustomListView rule in Pre-Upgrade Checker can warn that customized list views that will not be upgraded.  Read this article closely because for those of you that hate the List View Web Part as much as I do you’ll be extremely pleased to hear about the future direction of it.  Here’s a snippet from that article:

The following will not be upgraded to the new XSLT-based list view:

  • A list view that uses custom Collaborative Application Markup Language (CAML)
  • A list view that is not associated with a feature
  • A list view that is associated with a custom feature

A list view that is not upgraded will still render properly in Windows SharePoint Services 4.0. However, it will not inherit any benefits of the new XSLT-based list view, such as SharePoint Designer customization support, conditional formatting, and improved developer experience with XSLT standard-based language support.

The new XSLT-based list view is the default view that will be used in the next version release of Windows SharePoint Services. It will replace the existing list view in Windows SharePoint Services 3.0.

So there’s a couple of significant things with this article – the first is that we can now officially say that the List View Web Part, as a CAML based web part, is dead in the next version and will be replaced with a much better XSLT-based List View Web Part.  The second is that you now have some valuable information to keep in mind when doing custom development – avoid creating custom list views if you plan to upgrade to the next version.  To clarify the bullets above – based on my understanding (which could be wrong or could change) if you’ve customized a view via the browser you’re safe – but if you’ve customized the CAML directly using a tool or the API (within a Feature for example) then you will have to manually upgrade those views.

10 thoughts on “Custom List Views and WSS 4.0′s XSLT-based List View

  1. Nice catch. This is the first I’ve seen of the WSS 4.0 details confirmed. And so early, it’s not even Beta 1 and we have to worry about breaking changes?

  2. Yeah – the breaking change suck but it really is good news that they’re moving more towards XSLT. Plus, I’d rather know about these kinds of breaking changes now so that I can possibly change how I’m developing to avoid some upgrade issues.

  3. Gary,

    Do you have any insights on creating features for the next version? Since features are based on CAML in the current version, is there going to be a different way to create features then? I suppose current features might be broken?

    Just thinking out loud.


  4. Unfortunately I don’t (and to be honest even if I did I couldn’t share it due to NDA – I can only talk about what’s been publicly released). To speculate though – I’d say that we’ll be okay with Features – the reason being that the bulk of MOSS is built using Features so it would not be very advantages for MSFT to do something that completely breaks all of the existing stuff – I think there’ll be select pieces that may have to be reworked (custom field types for instance) but for the most part I’m speculating that we’ll be okay (that and the fact that the articles I reference (and their sister articles related to the pre-upgrade checker in SP2) don’t mention Features in general – just components).

  5. I happened to see the technical preview of SharePoint 2010.
    When can we expect similar preview for WSS 4.0?

    1. I’m not aware of any. I’ll be facing the same issue pretty soon myself – problem I’ve got is all the views are custom and not standard so I can’t just swap the web parts, I have to convert the CAML to XML (if you just have to swap the web parts then it might not be too hard with a bit of PowerShell but if you have to convert the CAML as I will then you’re in for a nightmare).

  6. I just have found if you manually open the .aspx file using SPD2010 and save it will convert to the new version, but I haven´t found any tool to modify automatically, in the file, In the the view section it makes some changes probably creating a script could help

Comments are closed.