This post describes an issue we were having using the SharePoint PageFieldFilter webpart in combination with a Lookup field. First the issue is explained, then a solution is provided.
The issue
In our intranet we were setting up a product catalog. The documentation for the products are stored in 1 document library. This doclib has a (multivalued) lookup field to the products list. We wanted to create 1 page per product in the same publishing site. This page will the the landing page for a product. It will show general information and the available documentation. To do this we added a lookup field to the Pages library to the same product list and added the PageFieldFilter webpart to the page. Turns out this does not work for a lookup field (the same applies to a user/group field).
Here is how you recreate this (it also shows the reasons why it doesn’t work):
- Create a Publishing site
- Create a list “Products” and add some items
- Create a document library “Documentation” and add some documents
- Add a (multivalued) lookup field to the document library
- Select product(s) for the documentation:
- Add a (singlevalued) lookup field to the Pages library
- Add a new page and select one of your products:
- Add the “Documentation” library to the page and show the name and product fields.
- Add the Page Field Filter webpart to the page and select the “Product” field.
- Connect the filter webpart to the Documentation list.
- Check-in and notice that the list shows no documents:
The filter webpart does not provide the correct value to the consuming webparts. In the screenshot below you will see why.After adding a TextFilter webpart to the page, you can set the default value for this text filter from the Page Field Filter webpart.
This shows our problem; the value is not the title of the selected item, but it is the value that SharePoint uses internally to store the value. This applies to both Lookup and Person or Group fields.
The solution
The solution for this is to build our own custom Page Field Filter webpart. You can do this by creating a new webpart that inherits from the ContextFilterWebPart in the Microsoft.SharePoint.Portal.WebControls namespace. Below I describe the most important bits to include in your code. My webpart is called “WebpageFieldFilter”.
- Create a private member and a property of type Guid (called “PageFieldID”)
- Create a new EditorPart that renders a dropdown showing all field in the pages library. These fields can be added directly from the context:
SPContext.Current.List.Fields
public override bool ApplyChanges()
{ WebpageFieldFilter webpart = WebPartToEdit as WebpageFieldFilter;
webpart.PageFieldID = new Guid(_selectField.SelectedValue);
return true;
}
public override void SyncChanges()
{ EnsureChildControls();
WebpageFieldFilter webpart = WebPartToEdit as WebpageFieldFilter;
_selectField.SelectedValue = webpart.PageFieldID.ToString("B"); }
- Implement the IWebEditable interface on your webpart. Implement CreateEditorParts. This should return the new EditorPart we just created, but also the EditorParts that are generated by the base webpart, otherwise we won’t have our filter options:
.cf { font-family: Courier New; font-size: 9pt; color: black; background: white; } .cl { margin: 0px; } .cb1 { color: teal; } .cb2 { color: blue; } EditorPartCollection IWebEditable.CreateEditorParts()
{ List<EditorPart> newEditors = new List<EditorPart>();
EditorPartCollection editors = base.CreateEditorParts();
foreach (EditorPart part in editors)
newEditors.Add(part);
newEditors.Add(new SelectListFieldEditor());
return new EditorPartCollection(newEditors);
}
- In the webpart class, override FilterConfigured and return true if our PageFieldID has a valid Guid value.
- In the webpart class, override DesignTimeHtml to return the correct text for your webpart in design mode.
- Override GetRawFilterValues to return the values for the field that was chosen by the user:
protected override string[] GetRawFilterValues()
{ SPListItem listItem = SPContext.Current.ListItem;
if (listItem != null && PageField != null)
{ SPField field = SPContext.Current.List.Fields[PageFieldID];
return GetFieldValues(listItem[PageFieldID], field);
}
return null;
}
After installing the webpart, you can add the new WebpageFieldFilter to the page and connect that to the Documentation library. When modifying the properties of the webpart, things look a bit different, because of the implementation of our custom EditorPart:
And when we look at the page, the documentation is now filtered as expected:
The webpart also works if you add a multivalued lookup field to the Pages library. It then provides all selected products in a string array to the consuming webparts. When I was testing this it looked like handling these multiple valued filters was not always correct. I’ll investigate this a bit further.
Enjoy!
You can find a WSP file containing a working version of the webpart. If you don’t know what to do with a wsp file, start looking at Chris Johnson’s blog, or use the SharePoint Solution Installer. Attached to this post, you will also find the full code for the webpart. Both are in the same ZIP file. Do whatever you like to do with them, but please let me know if you use them and what you think of it. Might give me some ideas to improve it. Enjoy!
