Content Roll-up options Part III – Data View Web Part

The Data View Web Part is sort of the Swiss-army knife of displaying data in SharePoint. It’s an Out-of-Box web part, and while it is typically focussed on showing items from a single list, it is capable of showing data from merged lists.

Here’s an example of a Data View Web Part showing the same data as our examples from the Content Query Web Part

Data View Web Part showing Merged data

It’s advantages are:

  • Can show a view with user defined filtering, grouping and sorting.
  • Has pagination of results
  • Showing extra columns of data is easy to add
  • Can filter the results by Content Type, or Metadata field values
  • Cheap (Out-of-box)
  • Designing the view is easy

It’s disadvantages are:

  • Requires SharePoint Designer – and therefore a suitably technical user
  • Can only query and merge results from a fixed set of sites – there is no ‘All Site collection’ or ‘This site and subsites option’
  • Limited by site collection boundary

In Short: Flexible in the views it presents, but it’s actual ability to roll up data is limited and could require constant maintenance. Requires someone fairly technical with SharePoint Designer to set view up. Continue reading “Content Roll-up options Part III – Data View Web Part”

Content Roll-up options Part III – Data View Web Part

Content Roll-up options Part II – Content Query Web Part

The Content Query Web Part is the Out-of-Box content roll-up web part in MOSS, and consequently it’s one of the most widely used.

Here’s an example of one rollup up the ‘Project Documents’ type:Standard content query web part

It’s advantages are:

  • Can select from an entire Site Collection, a Site and it’s Sub-Sites, or from a List
  • Can select by List type
  • Can filter the results by Content Type, or Metadata field values
  • Can be configured to do Sorting and Grouping
  • Can display custom data – but this is a little complex

It’s disadvantages are:

  • Customising the view is possible, but tricky.The view has to be defined in XSL, and the Content Query Web part configured correctly to get the data you want to display.
  • No pagination of results – it’s just truncated.
  • The user can’t select the results order, or add his own filter.
  • You can’t query across Site collections.

All in all, I’d say that defining the styles for what you want to display puts this into more a ‘development’ task, which isn’t ideal if you’re trying to push administration out to your users a bit more.

Also, a major issue as far as I’m concerned is the lack of pagination. You can limit the number of items shown, but without an link to the next ‘page’ of items.

Here’s an example of a Content Query Web Part showing some custom data (highlighted in yellow):

Content Query Web Part showing custom column data.

In short: Cheap, and available, but has that ‘just a bit awkward’ feel to setting it up, and lacks some of the features you’re likely to want. Often will require someone a bit technical for customisation. Continue reading “Content Roll-up options Part II – Content Query Web Part”

Content Roll-up options Part II – Content Query Web Part

Content Roll-up options Part I – Introduction

Well, I’ve been asked to examine some of the options for doing content roll-up in SharePoint. I thought I’d present this as a bit of a mini-series, rather than one huge post.

What is content roll-up? Simply, it’s about pulling data from different locations in SharePoint into a single view, and presenting it to the user in a consolidated form. This is a pretty common task in SharePoint. For example, think of things like roll-up of News items from the sites in your site collection. That’s actually built into the Collaboration site template:

News Items - and example of content roll up

I’ve bracketed both the web parts being used with red and blue – otherwise it’s not clear that there are two web parts doing content roll-up here – one for the most recent headline, and another to show a list of recent News items.

There are lots of other examples of where this is useful – consolidation of tasks for a user is another common requirement, or rolling-up all the documents of one type or another – such as expenses, etc..

Anyway, over the next week or so I’ll examine some of the solutions to content roll-up that I’ve seen. It’s not meant to be an exhaustive list – there are quite a lot of solutions to content roll-up around, and you can write your own – but why reinvent the wheel?

| Introduction | Content Query Web Part | Data View Web Part |

| Lightning Conductor Web Part | Bamboo’s List Roll-Up Web Part | Conclusions |

Content Roll-up options Part I – Introduction

Column Names when setting up the Content Query Web Part

So, I’ve been asked to do a look at content roll up options in SharePoint, such as the Content Query Web Part (CQWP), and one of the things I’ve been asked to do is to make it display custom column data. Now, there are lots of articles about this – on MSDN (here and here), Steven Van de Craen has an article about it, and there are lots of other articles about it (those were just the best resources I came across in a quick search). ‘Cos of that, I won’t repeat ’em – I’ll just summarise the steps:

  1. Add extra columns to the selected data (CommonViewFields) by exporting, editing and importing the web. part.
  2. Add a new display format to the ItemsStyle.xsl file.

Okay, so I did this, and one of my extra columns of data I wanted to present was shown (‘Project’), but the
other (‘Project Status’) wasn’t. What was going on?

Well, I sort of figured it was the space in the name – SharePoint does a funny encoding of spaces to _x0020_ which is annoying, and often causes errors. Anyway, I opened up SharePoint Manager to check what the field was called internally – and sure enough, it was called Project_x0020_Status. Fair enough, I’d got the internal name right, but using that still didn’t work.

I decided in the end to have a look at what the fields the CQWP was retrieving. But how to? I could define my own XSL, but I didn’t know what use to get the list of fields. Well, I found the answer on Bart Callaerts web site (actually, there is another good ‘how to customise the CQWP article). Anyway, I’m shamelessly plagiarising just in case that page in unavailable.

His idea was to define an Item Style to show all the columns of the retrieved items. The code for this is:

<xsl:template name="ViewFields" match="Row[@Style='ViewFields']" mode="itemstyle">
<xsl:for-each select="@*">
P: <xsl:value-of select="name()" />

And you can download a copy here – copying and pasting from this page can screw up so of the characters.

Anyway, I used this view to see my items:

Looking through that list of fields, I saw that the name of my column (according to the CQWP) is now Project_x005F_x0020_Status. That’s a bit strange, and I don’t know why that’s happened. I guess that Michael Hoffer’s suggestion (don’t use spaces in the names when you create the columns – add them later) is a good one – I reckon it’d have saved me this trouble!

Anyway, this suggestion worked nicely. I’ve highlighted my data in yellow:

Content Query Web Part showing custom column data.

Column Names when setting up the Content Query Web Part

Getting ListItems from throughout the Site Collection with SPSiteDataQuery

So, recently I was doing some work with SharePoint Web Services, getting possible values for Lookup fields. One of the functions I was using was GetListItems(), to get the values that the lookup field could take.

The method’s signature is:

Lists.GetListItems( [List], [ViewName], [Query], [ViewFields], [RowLimit], [QueryOptions], [WebID]);

I’m not going to talk about most of these parameters – you can read about them here. For my query, most of these parameters were Null (i.e. they were unused). However, the [List] parameter interested me. It’s the ‘Name’ of the list, though I prefer using a GUID (a unique ID) for the list.

The lookup column I was using was defined in a different site to the one where I was making the GetListItems call. I’d pass the GUID, and get the correct values back. My call actually was:

XmlNode resultNode = _lists.GetListItems( listGuid, null, null, viewFields, null, null, null);

So, this query was finding the correct list elsewhere in the site collection based only on the GUID. Interesting – I’m not passing a WebID, and the list is outside the site I’m currently using the web services of. This set me thinking – clearly the call was selecting by list GUID against a table of all ListItems in the site collection.

I was a little surprised – then it hit me – the Content Query Web Part also does that. But how?

Well, a bit of searching later and I found the SPSiteDataQuery object. The object is used for queries against multiple lists in multiple sites. You can specify the types of list to query, values to filter, order by, display, etc.. I’m pretty sure that this is what the Content Query Web Part uses.

Neat! Now I just need to find a reason to use it!

Getting ListItems from throughout the Site Collection with SPSiteDataQuery

Content Query Web Parts and Site Categories

Here’s a thought – wouldn’t it be cool to have a way of getting content from Sites in a Site Collection, but filtered by their category data?

At the moment, the Content Query Web Part gives you 3 options as to what sites it queries:

  1. A specific site
  2. This site and its children
  3. All sites in the collection

Wouldn’t it be great, though, to form that list of target sites based on a category? For example, in a big company it may have a number of divisions, each with their own ‘Finance’ department. A content query web part that could show content from all the ‘Finance’ category sites across the organisation would be very cool.

Can’t see a way of doing it at the moment though. I suppose I could write my own web-part – but the Content Query Web Part gives you so much already, I don’t want to have to replicate that.

Content Query Web Parts and Site Categories