Leveraging SharePoint Web Part capabilities

I'm stuck. I think I'm caught between a rock and a hard place.

Currently with SharePoint you have 3 ways to create web parts.

  1. Define the views and all that stuff and drop it on a page.
  2. Create a DataView Web Part (with FP2003) and drop it on the page.
  3. Create everything from scratch.

With the first two options, you can get all kinds of nice features like column sorting, filtering, etc. Free. No coding required. With the second option, you can have all kinds of great business logic happening to render your information. Run off and talk to SAP, suck some data out of your corporate Oracle system, do some financial calculations, whatever. Then fire it off the web page all nice and neat for the user. Problem is that I can't find any !%@#$%$# way to find a happy balance between the two.

What if you want to aggregate across multiple types of items or items that don't exist in a single library or list (like a domain collection)? Let's say I have 500 sites under a portal and each one has a Task list on it (we'll assume they're all from the same site definition). I write a web part to recurse through all the sites, grabbing the task list and finding all tasks assigned to Me and want to display them in my custom web part, with filtering, paging, sorting, etc. that the ListViewWebPart provides (assuming I have a list to point it at). I can't because I have nothing to point the listview at. Unless I create a new list on the fly (ugh) and populate it, but that's just plain ugly.

ListViewWebPart would be nice to inherit from then specify your own data source (overriding the GetData method). However pretty much all of the classes in Microsoft.SharePoint.* are sealed (except for WebPart) so that's the only thing you can inherit from. For example, when you drag a web part onto a page, SharePoint will use the ListViewWebPart from it's arsenal to give you all those features people want (sorting, filtering, etc.). However you can't inherit from ListViewWebPart, only WebPart. The DataView Web Part is the same. I have to point it at a data source. Grant you it's a little easier because you could point it at a web service and have your web service do the heavy lifting, but still it's not very elegant or easy for that matter and I've never seen anyone do it.

Anyone have any insight into how to bridge what I think is a gap here? While you can't inherit from a ListViewWebPart or a DataViewWebPart, you can construct them in your custom web part. Problem is you're still stuck having to point them at a physical source of information rather than a collection of domain objects.

1 Comment

  • The strategy we're looking at is a server-side script (aspx that returns xml) that aggregates list based on criteria passed in to the page as parameters (probably XML that is encoded to be URL acceptable). Sort of Web Services Lite. The XML we return is the same format as what you'd get from the SharePoint web service or server-side script for a given list, modified to include information about which list it comes from.



    We're really hoping Microsoft addresses this in SharePoint v.Next. CorasWorks has a solution for this, but we don't have much of a budget for SharePoint enhancement.

Comments have been disabled for this content.