Paging Content Query Web Part

We all know the Content Query Web Part shipped with MOSS 2007. It is so far the best content aggregation solution available. While it is extremely flexible and allows you to define your own presentation layer, it lacks some basic aggregation features like results paging and dynamic content filtering. While Andrew Connell has presented recently a nice approach to achieve last one, I have decided to focus on the paging functionality.

Customizing the Content Query Web Part isn’t always as easy, as many of us SharePoint developers would like it to be. Next to some general programming skills and knowing the SharePoint object model you have to do some digging on how the CQWP works and where it allows you to plug in. One of the greatest example of customizing the CQWP is the Enhanced Content Query Web Part by Ishai Sagi. If you’re interested in extending the CQWP it is definitely a nice point to start. Back to the paging…

I don’t think I need to explain the idea of paging results: a Web Part supporting paging should give you at least the possibility to define how many items you want to display per page.

The Pager

I took the requirements a step further: I have decided to detach the Paging functionality from the CQWP so that if you don’t want it at a particular place, you can simply “turn it off” and use the regular CQWP functionality. To provide that flexibility I have decided to use the concept of connectable Web Parts and let the CQWP send the required paging information to the Pager Web Part. The data displayed by the CQWP would change upon selecting a page. Two problems arise at this point.

First of all the pager would have to be a consumer and provider at the same time. Based on the retrieved paging data (how many pages are there, and which page are we currently on) it would render the pager. After selecting a page it would provide this information to the CQWP so it can modify the displayed data. While a Web Part can be both consumer and provider at the same time, it can’t be done to retrieve and provide data to one and the same Web Part at the same time.

Another issue arises when considering accessibility. By providing the current page information using the Web Part Connection concept, there is now way of accessing the particular results page by using the URL only. The current page information is being stored in the interface which both Web Parts implement, but you cannot persist it in the URL.

In order to solve both issues, I have decided to make the Pager Web Part a receiver and let the CQWP use a query string parameter to determine the current page. By placing that information in the interface both Web Parts implement, the CQWP knows which variable contains the information about the current page and the Pager Web Part knows which variable it should use for rendering the links to particular pages.

As for the presentation layer I have decided to leverage the concept presented by the CQWP and support XSL. The Pager itself produces XML which can be modified to suit any chrome using XSL.

Extended Content Query Web Part

The Extended CQWP supports paging by using a query string parameter. After setting the basic properties: number of items per page and the name of the query string parameter which contains the current page number, the paging is on.

I will try to provide a ‘How I did it’ with some more details on the Web Part next week. In the meanwhile you can download the wsp containing both Web Parts and check them out.

Technorati Tags: SharePoint, SharePoint 2007, MOSS 2007, WCM