Really, just a reminder for myself, but if you work with SharePoint long enough you’re bound to end up using something like the Content Query Web Part or a Data View Web Part to aggregate and output a rich text source – but all your HTML gets escaped, so it appears content on the page.
The command you want is DisableOutputEscaping:
<xsl:value-of select="somevalue" disable-output-escaping="yes" />
This will cause the HTML to be output unescaped – i.e. as HTML.
Side note: Sometimes people want things like the CQWP to show the first part of the content as a ‘summary’. This trucating content to display in the CQWP or DVWP is difficult; either a) you risk having unfinished tags in the HTML you do emit, or b) you have to strip out all HTML, which can ruin your formatting. a) is a particular problem, as unfinished <table> tags can cause all sorts of weirdness on page.
My preferred option is to have a additional ‘summary text’ box that accepts plain text, and have the author generate the summary manually. That way we avoid outputting HTML like that entirely.
Thrilling title, eh? So, previously I’ve talked about merged lists in the Dataview web part. This time, I was after something slightly different – rather than merging two lists, I wanted to join them.
Joining is pretty easy, actually, but the process is a little bizarre. I ended up using the post ‘Performing Joins with SharePoint Lists‘ by Sahil Malik. The thing that confused me was that when I was I expected to provide the ‘keys’ of my lists when I created the new Datasource – but actually, you define it when you insert your ‘joined subview’.
Anyway, the scenario was that there are customer purchases for ‘Credits’ to do things. Operatives then do things for them, and these actions subtract time off those pools of credits. The need was for a way to:
- Record purchases of pools of credits. Customers may purchase multiple times, but under different agreements (or invoices, or whatever)
- Record actions and the number of credits that they cost
- Remaining total.
I solved this with a Dataview web part, and two lists. Continue reading “Linking list data and summing over it with XSL and the Dataview Web Part”
I’d a question from a reader (gee, I have readers!) about doing content rollup using the DataView web part. He was asking if he could use the DataView web part even though the things he was pulling into his Data Source didn’t all have the same columns. Would this work? Well, one way to find out… Continue reading “Merged Data Sources for the DataView web part”
SharePoint is made up of lists of items, where an item is a set of data. Here is the standard display of an item’s properties:
As you can see, we’ve got a item, and it has some fields of data, and they’re being displayed inside a web part. Those fields are columns on the list:
All very familiar, I’m sure. It gets interesting when we start using Lookup columns, though. These are columns that refer to items in other lists. For example, this is a list of documents, but they refer to items in the above list (that’s what the Item Ref column is doing):
Cool, but wouldn’t it be great if I could show a list of items referring to a particular item on it’s display page? For example, in this case wouldn’t it be good to show a list of ‘Item Documents’ on the DispForm.aspx page used to show the Item’s properties? Well, you can:
(Edit: one of my colleagues points out that Microsoft did this in one of the Fab 40 templates – but I didn’t know).
So how does it work? Continue reading “Modify ListItem Display to show referencing items…”
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
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”