Mike Donovan’s post got me interested in how IRuntimeFilter could be used to replicate SharePoint Portal Server audience/targeting feature in Windows SharePoint Services. There are several situations I’ve run into where the SPS targeting is a compelling feature for Portal Server but the limitation of 10,000 areas was a problem. (By way of reference, I also found Serge van den Oever’s reverse engineering of the interface which was very good.)
In thinking about the interface it also seemed promising as a potential way to secure web parts. In other words, with an IRuntimeFilter running you could potentially turn off web parts for certain groups of users. This might be effective at preventing them from seeing our using web parts from the gallery that some users needed but weren’t suitable for everyone.
However, the actual implementation of the interface appears to have a few challenges. (I have a case open with MS PSS right now to verify some of these observations. I’ll update this blog entry or more likely add a new one when I get more information.)
- The filter is only called when the IsIncludedFilter property in the web part has a non-empty (non-null value.) In other words, you don’t get the opportunity to inspect every web part as it’s loaded, you only get to inspect those web parts with the property set. This makes it useful for user configuration but not very useful as a “traffic cop.”
- The interface doesn’t specify any information about the web part itself. It only returns to you a filter string that you presumably created with the user interface. The challenge with this is that there is no way (I’ve found) to determine just which web part is trying to be displayed. Again, maybe this isn’t an issue for users configuring things for themselves, but it seems awfully limiting. One reason is because when a web part is exported and re-imported, the IsIncludedFilter property stays with it. That means that if you have site-specific data in the IsIncludedFilter property it becomes invalidated when it moves to the next site. This is a real problem when trying to move web parts between sites or punch out a template site. (The Microsoft provided ListViewWebPart andListFormWebPart both exhibit problems when you try to move them from one site to another due to this same fundamental issue of using site/area specific property values. This is why you are not allowed to export and import ListViewWebParts via the user interface.)
- The ValidateIsIncludedFilter() method, which is called when the property is saved is called all the time. There’s no event which fires when the user adds the web part or changes the configuration. This event fires every time the web part is saved. This appears to be happening on every page load – which is a bad thing in and of itself that I don’t really understand. Why would we be saving a web part back to the database every time it’s rendered? It seems to me that this would be a huge performance problem.
- The IRuntimeFilter is only called in “personalization mode” The precise meaning of this eludes me – I can’t find the definition in the documentation. However, based on observation it appears that it is only called in the personal view of the site. (This would be the view that few people actually see first, only those who have the permission to personalize the site and have done so default to a personal view of the site – almost everyone gets a shared view.) The net effect of this is that it’s going to require some more work to force people into a personal view by default when they view a WSS page.
- The IRuntimeFilter interface is only called for “global” web parts on a page. That means if the user adds a web part to their page while in personal mode the IRuntimeFilter will never control whether it is displayed or not.As a sidebar, it appears that SPS enters personalization mode or the “my page” view by default since their IRuntimeFilter is turned on. I tried playing with this and observed that when I put a SharePoint Area into edit mode and then switched to personal view all of my menus disappeared. All I could do was return to Shared mode which would allow me to edit what web parts were on the page, etc. Based on these observations it looks like SPS is actually putting the area into a personal view every time the page is loaded but they also don’t allow you to personalize the page.
So, I can probably replicate the SPS audiences using IRuntimeFilter if I can figure out how to force the WSS sites to default in personal view even for those without any personalization to the site.
However, without some way of inserting the web part storage key or some other value into the IsIncludedFilter property of a web part while it’s being imported, I’m not sure how to make this interface any more useful than the SPS application of it. I’ve not found a way to inject properties to every web part as it’s added yet…
Is anyone else playing with this interface?
No comment yet, add your voice below!