In this post I described a custom filter provider and consumer webpart for Microsoft Office SharePoint Server 2007. In this post I show how you can make the provider send a default value to other filter webparts. The second step is to show how you can make a webpart accept an incoming default value from another filter webpart. At the end of this post I will give an example of how you can use your filter provider in combination with Excel Services.
Step 1 – Provide a default value
We will change the behaviour of our provider webpart so that it is able to send filter values and a default value to other webparts. Please note that a default value is always single valued. For a webpart that supports multiple values, multiple default values seem not to be supported by the framework. The first thing to do is implement the IDefaultFilterValue interface:
public class FilterProvider :
System.Web.UI.WebControls.WebParts.WebPart,
ITransformableFilterValues,
IDefaultFilterValue
In the implementation the value of the first selected checkbox is sent to the consumer of the default value. This is just the first selected value, because the framework only support single valued default values:
public string DefaultValue
{ get
{ for (int i = 0; i < _regions.Items.Count; i++)
{ if (_regions.Items
.Selected)
return _regions.Items.Value;
}
return null;
}
}
The last thing to do is notify the WebPartManager that we now support default values:
[ConnectionProvider(
"Default region",
"UniqueIDForRegionDefault",
AllowsMultipleConnections = true)]
public IDefaultFilterValue SetDefaultValueConnection()
{ return this;
}
As described in the previous post, the ConnectionProvider attribute has 3 parameter. The first in de snippet above is the displayname. This shows up when you connect your provider to another filter webpart:
Step 2 – Test the default value provider
The easiest way to test your filter provider is to use the Text Filter WebPart as the consumer. Add both webparts to the page and send the “Default region” to the text filter webpart. After selecting a value you webparts will look like this:
Step 3 – Consume default values
In this step we will change the provider webpart to make it support incoming default values. It will support multiple connections, so that we can setup multiple webparts on our page that can pass a default value to our webpart. Because we support multiple incoming default values, we setup a private member that will hold our connections:
private List<IDefaultFilterValue> _defaultValues;
private List<IDefaultFilterValue> DefaultValues
{ get { return _defaultValues; } }
public FilterProvider()
{ _defaultValues = new List<IDefaultFilterValue>();
}
The only other thing to do is to notify the WebPartManager that we now support incoming default values.
[ConnectionConsumer(
"default region",
"UniqueIDForRegionDefaultConsumer",
AllowsMultipleConnections = true)]
public void SetFilter(IDefaultFilterValue defaultFilterValue)
{ if (defaultFilterValue != null)
{ DefaultValues.Add(defaultFilterValue);
}
}
Again, this attribute takes 3 parameter, where the displayname is used in setting up the connection when initiated from the consuming webpart:
In the OnPreRender of our provider webpart, we need to handle the incoming default values:
protected override void OnPreRender(EventArgs e)
{ foreach (IDefaultFilterValue defaultValue in DefaultValues)
{ if (!string.IsNullOrEmpty(defaultValue.DefaultValue))
{ foreach (ListItem region in _regions.Items)
if (string.Compare(region.Value, defaultValue.DefaultValue, true) == 0)
region.Selected = true;
}
}
base.OnPreRender(e);
}
Step 4 – Test the default value consumer
To test the we add the provider webpart to the page and also a Current User Filter webpart. The current user filter webpart reads the value of one of the profile properties and passes that as the default value to our region selector. By managing the profile property for our users, users now automatically have their default region selected when they hit the page.
The Current User Filter webpart is a context filter webpart and therefore is not visible at runtime. When the page is in edit mode, it looks like this:
In this screenshot you see 3 webpart:
- Current user filter – reads the value from my user profile
- FilterProvider – gets the default value from the first webpart and passes its value as the default value to the text filter webpart
- Default region – text filter webpart that gets a default value from the FilterProvider.
Of course this testscenario is not very useful, but it shows that you can use MOSS filter webparts to build pages that make it easy for users to select the content they wish to see. By using default values it makes it even easier. I have used the “Office” property of my profile to set the default value for the users:
The screenshot below shows that our default value consumer supports multiple default values. By using this mechanism, we can set multiple default values in our webpart, but just 1 for each incoming connection. This page has 2 text filter webparts that both send their value as the default value to our FilterProvider webpart:
Step 5 – Test our provider with Excel Services
Filter webparts can also be used to send input to Excel sheets rendered in an Excel Web Access webpart. In the screenshot below you see our provider webpart that sends the selected values to a parameter in the Excel sheet. This Excel sheet shows a pivot table the gets it data from the Analysis Services demo cube Adventureworks.
The Excel Web Access webpart supports 3 types of connections. I used the connection type “Get Filter Values From”. When configuring the connection in the second step (see screenshot below), you can select the named parameters in the sheet.
You can name these parameters when you publish the Excel sheet. When I published my report, I created a parameter called “Geo”:
The only thing I changed to the provider are the available options. Because we now are sending values to Excel Services that connects to Analysis Services, we need to send MDX instead of plain text. My provider is now setup like this. The exact syntax of the MDX of course depends on the dimensions in the cube.
protected override void CreateChildControls()
{ base.CreateChildControls();
_regions = new CheckBoxList();
_regions.Items.Add(new ListItem("Australia", "[Geography].[Geography].[Country].&[Australia]")); _regions.Items.Add(new ListItem("Canada", "[Geography].[Geography].[Country].&[Canada]")); _regions.Items.Add(new ListItem("France", "[Geography].[Geography].[Country].&[France]")); _regions.Items.Add(new ListItem("Germany", "[Geography].[Geography].[Country].&[Germany]")); _regions.Items.Add(new ListItem("United Kingdom", "[Geography].[Geography].[Country].&[United Kingdom]")); _regions.AutoPostBack = true;
this.Controls.Add(_regions);
}
By using Excel combined with the out of the box SharePoint filter web parts and your own, you have very flexible, powerful reporting mechanism.