Monthly Archives: December 2007

Create Bar Graphs in SharePoint

Overview:

(UPDATE 12/04/07: Added another interesting resource at the end linking to another blog that addresses this via a very interesting web part)

This blog entry describes how to create a bar graph in SharePoint.  This works in both WSS and MOSS environments as it only depends upon the data view web part.

The overall approach is as follows:

  1. Create a list or document library that contains the data you want to graph.
  2. Place the associated document library / custom list onto a page and convert it to a data view web part (DVWP).
  3. Modify the DVWP’s XSL to generate HTML that shows as a graph.

Business Scenario / Setup:

I have created a custom list with the standard Title column and one additional column, "Status".  This models (very simplistically) an "Authorization For Expense" scenario where the title represents the project and the Status a value from the list of:

  • Proposed
  • In Process
  • Stalled

The objective is to produce an interactive horizontal bar graph that shows these status codes.

I have populated the list and it looks like this:

image

Create Data View Web Part:

Create the DVWP by adding the custom list to a page (site page in my case) and follow the instructions here (http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!395.entry).

In addition to simply creating the DVWP, we also need to set the paging property to show all available rows.  For me, this looks something like this:

image

At this point, I always close SPD and the browser.  I then re-open the page using the browser.  This avoids accidentally mucking up the web part layout on the page.

Modify the XSLT:

It’s now time to modify the XSLT.

I always use visual studio for this.  (See here for an important note about intellisense that will help you a lot).

I create an empty project add four new files (replacing the words "Original" and "New" as appropriate):

  • Original.xslt
  • New.xslt
  • Original Params.xml
  • New Params.xml

In my case, it looks like this:

image

Modify the web part and copy the params and XSL to the "Original" version in Visual Studio.

The objective here is to cause the XSL to transform the results we get back from the DVWP query into HTML that renders as a graph.

To this end, it helps to first consider what the HTML should look like before we get confused by the insanity that is known as "XSL".  (To be clear, the following is simply an example; don’t type it or copy/paste into visual studio.  I provide a full blow starting point for that later in the write-up).  The following sample graph is rendered as per the HTML immediately following:

Sample Bar Graph

Corresponding HTML:

  <html>
  <body>
    <center>
    <table width=80%>
      <tr><td><center>Horizontal Bar Graph</td></tr>
      <tr>
        <td align="center">
          <table border="1" width=80%>
           <tr>
              <td width=10%>Open</td>
              <td><table cellpadding="0" cellspacing="0" border=0 width=50%><tr bgcolor=red><td>&nbsp;</td></tr></table></td>
            </tr>
            <tr>
              <td width=10%>Closed</td>
              <td><table cellpadding="0" cellspacing="0" border=0 width=25%><tr bgcolor=red><td>&nbsp;</td></tr></table></td>
            </tr>
            <tr>
              <td width=10%>Stalled</td>
              <td><table cellpadding="0" cellspacing="0" border=0 width=25%><tr bgcolor=red><td>&nbsp;</td></tr></table></td>
            </tr>
          </table>
        </td>
      </tr>
    </table>
  </body>
</html>

I used a dead simple approach to creating my bars by setting the background color of a  row to "red". 

The take-away here is this: In the end, all we are doing is creating HTML with rows and columns.

Template XSLT:

I’ve copied the XSLT that generates a horizontal bar graph.  It’s fairly well commented so I won’t add much here except for these notes:

  • I started with the default XSL that SharePoint Designer gave me when I first created the DVWP.
  • I was able to cut this down from SPD’s 657 lines to 166 lines. 
  • I didn’t mess around with the parameters XML file (which is separate from the XSL and you’ll know what I mean when you go to modify the DVWP itself; there are two files you can modify).  However, in order to simplify it, I did remove nearly all of them from the XSL.  This means that if you want to make use of those parameters, you just need to add their variable definitions back to the XSL.  That will be easy since you will have the original XSL variable definitions in your visual studio project.
  • You ought to be able to copy and paste this directly into your visual studio project.  Then, remove my calls and insert your own calls to "ShowBar".
  • The drill down works by creating an <a href> like this: http://server/List?FilterField1=fieldname&FilterValue1=actualFilterValue.  This technique may be of value in other contexts.  At first, I thought I would need to conform to a more complex format: http://server/List/AllItems.aspx?View={guid}&FilterField1=blah&FilterValue1=blah, but in my environment that is not necessary.  The List’s URL is passed to us by SharePoint so this is quite easy to generalize.

Here it is:

 
<xsl:stylesheet version="1.0" exclude-result-prefixes="rs z o s ddwrt dt msxsl" 
xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:SharePoint="Microsoft.SharePoint.WebControls" xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer"
xmlns:asp="http://schemas.microsoft.com/ASPNET/20" xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime"
xmlns:o="urn:schemas-microsoft-com:office" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882"
xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema"
xmlns:ddwrt2="urn:frontpage:internal"
> <xsl:output method="html" indent="no" /> <xsl:decimal-format NaN="" /> <xsl:param name="ListUrlDir"></xsl:param> <!-- I need this to support a drill-down. --> <xsl:template match="/" xmlns:SharePoint="Microsoft.SharePoint.WebControls"
xmlns:__designer=http://schemas.microsoft.com/WebParts/v2/DataView/designer xmlns:asp="http://schemas.microsoft.com/ASPNET/20"
> <xsl:variable name="dvt_StyleName">Table</xsl:variable> <xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row" /> <xsl:variable name="dvt_RowCount" select="count($Rows)" /> <xsl:variable name="IsEmpty" select="$dvt_RowCount = 0" /> <xsl:variable name="dvt_IsEmpty" select="$dvt_RowCount = 0" /> <xsl:choose> <xsl:when test="$dvt_IsEmpty"> There is no data to graph!<br/> </xsl:when> <xsl:otherwise> <!-- The interesting stuff begins here. We need to define a pair of variables for each row in the graph: total number of items and percent of total. --> <xsl:variable name="totalProposed" select="count(/dsQueryResponse/Rows/Row[normalize-space(@Status) = 'Proposed'])" /> <xsl:variable name="percentProposed" select="$totalProposed div $dvt_RowCount" /> <xsl:variable name="totalInProcess" select="count(/dsQueryResponse/Rows/Row[normalize-space(@Status) = 'In Process'])" /> <xsl:variable name="percentInProcess" select="$totalInProcess div $dvt_RowCount" /> <xsl:variable name="totalStalled" select="count(/dsQueryResponse/Rows/Row[normalize-space(@Status) = 'Stalled'])" /> <xsl:variable name="percentStalled" select="$totalStalled div $dvt_RowCount" /> <!-- We define our HTML table here. I'm borrowing from some standard SharePoint styles here to make it consistent. I think it will honor changes to the global css file as well as theme overrides. --> <table width="100%" cellspacing="0" cellpadding="2" style="border-right: 1 solid #C0C0C0; border-bottom: 1 solid #C0C0C0; border-left-style: solid; border-left-width: 1; border-top-style: solid; border-top-width: 1;"> <tr> <td align="center"> <table border="1" width="100%"> <!-- For each status that we want to graph, we call the "ShowBar" template. We pass it: 1. A label for the row. This is transformed into a hyperlink. 2. The percent (variable from above). 3. The actual field name of the code from the underlying list. This does not need to match the display label. 4. Field value matched for #3. 5. Total items of this status code (not the grand total of all status codes). It emits a <tr></tr> and the horizontal bar graph line. We call this template for each status code we want to view. --> <xsl:call-template name="ShowBar"> <xsl:with-param name="BarDisplayLabel" select="'Proposed'"/> <xsl:with-param name="BarPercent" select="$percentProposed"/> <xsl:with-param name="QueryFilterFieldName" select="'Status'"/> <xsl:with-param name="QueryFilterFieldValue" select="'Proposed'"/> <xsl:with-param name="TotalItems" select="$totalProposed"></xsl:with-param> </xsl:call-template> <xsl:call-template name="ShowBar"> <xsl:with-param name="BarDisplayLabel" select="'Stalled'"/> <xsl:with-param name="BarPercent" select="$percentStalled"/> <xsl:with-param name="QueryFilterFieldName" select="'Status'"/> <xsl:with-param name="QueryFilterFieldValue" select="'Stalled'"/> <xsl:with-param name="TotalItems" select="$totalStalled"></xsl:with-param> </xsl:call-template> <xsl:call-template name="ShowBar"> <xsl:with-param name="BarDisplayLabel" select="'In Process'"/> <xsl:with-param name="BarPercent" select="$percentInProcess"/> <xsl:with-param name="QueryFilterFieldName" select="'Status'"/> <xsl:with-param name="QueryFilterFieldValue" select="'In Process'"/> <xsl:with-param name="TotalItems" select="$totalInProcess"></xsl:with-param> </xsl:call-template> </table> </td> </tr> </table> </xsl:otherwise> </xsl:choose> </xsl:template> <!-- This template does the work of displaying individual lines in the bar graph. You'll probably do most of your tweaking here. --> <xsl:template name="ShowBar"> <xsl:param name="BarDisplayLabel" /> <!-- label to show --> <xsl:param name="BarPercent"/> <!-- Percent of total. --> <xsl:param name="QueryFilterFieldName"/> <!-- Used to jump to the query & filter --> <xsl:param name="QueryFilterFieldValue"/> <!-- Used to jump to the query & filter --> <xsl:param name="TotalItems" /> <!-- total count of this barlabel --> <tr> <!-- The bar label itself. --> <td class="ms-formbody" width="30%"> <!-- This next set of statements builds a query string that allows us to drill down to a filtered view of the underlying data. We make use of a few things here: 1. We can pass FilterField1 and FilterValue1 to a list to filter on a column. 2. SharePoint is passing a key parameter to us, ListUrlDir that points to the underlying list against which this DVWP is "running". Isn't XSL fun? --> <xsl:text disable-output-escaping="yes"> <![CDATA[<a href="]]></xsl:text> <xsl:value-of select="$ListUrlDir"/> <xsl:text disable-output-escaping="yes"><![CDATA[?FilterField1=]]></xsl:text> <xsl:value-of select="$QueryFilterFieldName"/> <xsl:text disable-output-escaping="yes"><![CDATA[&FilterValue1=]]></xsl:text> <xsl:value-of select="$QueryFilterFieldValue"/> <xsl:text disable-output-escaping="yes"><![CDATA[">]]></xsl:text> <xsl:value-of select="$BarDisplayLabel"/> <xsl:text disable-output-escaping="yes"><![CDATA[</a>]]></xsl:text> <!-- The next bit shows some numbers in the format: "(total / % of total)" --> (<xsl:value-of select="$TotalItems"/> / <!-- This creates a nice percent label for us. Thanks, Microsoft! --> <xsl:call-template name="percentformat"> <xsl:with-param name="percent" select="$BarPercent"/> </xsl:call-template>) </td> <!-- Finally, emit a <td> tag for the bar itself.--> <td> <table cellpadding="0" cellspacing="0" border="0" width="{round($BarPercent*100)+1}%"> <tr bgcolor="red"> <xsl:text disable-output-escaping="yes"><![CDATA[&nbsp;]]></xsl:text> </tr> </table> </td> </tr> </xsl:template> <!-- This is taken directly from some XSL I found in an MS template. --> <xsl:template name="percentformat"> <xsl:param name="percent"/> <xsl:choose> <xsl:when test="format-number($percent, '#,##0%;-#,##0%')= 'NaN'">0%</xsl:when> <xsl:otherwise> <xsl:value-of select="format-number($percent, '#,##0%;-#,##0%')" /> </xsl:otherwise> </xsl:choose> </xsl:template> </xsl:stylesheet>

The Results:

The XSL from above generates this graph:

image

Drill down to the underlying data by clicking on the status code:

image

Concluding Thoughts:

Can This Be Generalized?

I love this graphing concept, but I hate the fact that I have to go in and do so much hand-coding.  I’ve given a little thought to whether it can be generalized and I’m optimistic, but I’m also a little fearful that there may be a brick wall somewhere along the path that won’t offer any work-around.  If anyone has some good ideas on this, please make a note in the comments or email me.

Vertical Graphs:

This is a horizontal bar graph.  It’s certainly possible to create a vertical graph.  We just need to change the HTML.  I would start the same way: Create an HTML representation of a vertical bar graph and then figure out how to get that via XSL.  If anyone is interested in that, I could be persuaded to try it out and work out the kinks.  If someone has already done that, please let me know and I’ll gladly link to your blog 🙂

I think that challenge with a vertical graph is that the labels for the graph are more difficult to manage, but certainly not impossible.

Field Name Gotcha’s:

There are at least two things to look out for with your field names.

First, a field name with a space has to be escaped in the XSL.  This will probably be an issue here:

        <xsl:variable name="totalProposed" 
select="count(/dsQueryResponse/Rows/Row[normalize-space(@Status) = 'Proposed'])" />

If your "Status" column is actually named "Status Code" then you need to reference it as "Status_x0020_Code":

   <xsl:variable name="totalProposed" 
select="count(/dsQueryResponse/Rows/Row[normalize-space(@Status_x0020_Code) = 'Proposed'])" />

Second, and I’m a little fuzzy on this, but you also need to be on the alert for field name changes.  If you name your field "Status Code" and then later on, rename it to "AFE Status", the "internal name" does not change.  The internal name will still be "Status Code" and must be referenced as "Status_x0020_Code".   The "other resources" links may help diagnose and correct this kind of problem.

About that Color:

I picked "red" because it’s pleasing to me at the moment.  It would not be a big deal to show different colors so as to provide more than just a visual description of a number, but to also provide a useful KPI.  For example, if the percentage of "stalled" AFE’s is > 10% then show it red, otherwise show it in black.  Use <xsl:choose> to accomplish this.

Other Resources:

Happy transforming!

<end/>

 Subscribe to my blog!

SharePoint Does Not Provide “Who Has Access” Reports

UPDATE 01/28/08: This codeplex project addresses this issue: http://www.codeplex.com/AccessChecker.  I have not used it, but it looks promising if this is an issue you need to address in your environment.

UPDATE 11/13/08: Joel Oleson wrote up a very good post on the larger security management issue here: http://www.sharepointjoel.com/Lists/Posts/Post.aspx?List=0cd1a63d%2D183c%2D4fc2%2D8320%2Dba5369008acb&ID=113.  It links to a number of other useful resources.

Forum users and clients often ask a question along these lines: "How do I generate a list of all users with access to a site" or "How can I automatically alert all users with access to list about changes made to the list?"

There is no out of the box solution for this.  If you think about it for a moment, it’s not hard to understand why.

SharePoint security is very flexible.  There  are at least four major categories of users:

  • Anonymous users.
  • SharePoint Users and Groups.
  • Active Directory users.
  • Forms Based Authentication (FBA) users.

The flexibility means that from a security perspective, any given SharePoint site will be dramatically different from another.  In order to generate an access list report, one needs to ascertain how the site is secured, query multiple different user profile repositories and then present it in a useful fashion.  That’s a hard problem to solve generically.

How are organizations dealing with this?  I’d love to hear from you in comments or email.

</end>