A very small group of you saw this post go up and then come right back down again. I found a bug about 30 seconds after posting this. Here is the updated post. NOTE: The bug had to do with not fully understanding how the pagination handled moving backwards in the list. It appeared to be doing it correctly, but when I started to look closely at the actual items, it turned out that it was ALWAYS MOVING FORWARD. The key is that I missed the PagedPrev query string element, which I now am including correctly. The code has been updated below. Beware of of voodoo programming.
It seems like everything takes just a little longer to learn than it should with SharePoint. I am building a webpart that browses list items and allows the user to perform special actions on the list item. After creating item styles and coming up with a CSS container to match the repeating pattern I needed, I went to add pagination to the item browser. Pagination is usually represented in the user interface by little left-right arrows or “next page”/”previous page”. This should be easy and it is, once you understand how SharePoint does pagination.
The key to SharePoint list pagination is the SPListItemCollectionPosition class. The documentation’s one example didn’t help me with my specific requirements. In particular, I need to page through the list data sorted by the “Created” date field.
The SPListItemCollectionPosition’s constructor takes one string parameter called PagingInfo. The SDK’s description of this parameter is particularly useless: Gets or sets paging information used to generate the next page of data. What about the string’s structure and contents? How do you use it? Another friendly MSDN blogger, Deepak Badki, had part of the answer here.
But rather than just copy his code, I needed to understand it first.
If you setup a list view such that it is sorted and the number of items to display is less than the number of items, you can examine the query strings resulting from paging from one page to the next and back. Here are some examples:
In this particular instance, the list view is configured to sort by the created date. Let’s break down the the query string:
AllItems.aspx? – The list page
Paged=TRUE – Indicates that the list is paged.
PagedPrev=TRUE – This element only appears when the previous page is visited.
p_Created= – The first sort by parameter, which is “Created” prefixed with “p_”. The right hand is the encoded universal date and time.
p_ID= – This is the ID of the previous page’s last item’s ID. This is important.
View= – This is the encoded GUID for the current list.
PageFirstRow= – The ID of the current page’s first item.
Newbie Webpart Developer
I am definitely new to webpart development. I have done some work in ASP.NET but not for a while. I know that sounds strange given that so much of what we do involves web development, but I have been a back-end guy for a long, long time. So, this is really exciting for me and a bit painful. ASP.NET’s attempt to be like WinForms in many ways offers tremendous advantage, but it also is a bit like taking a boat on land. I am also exploring the MVC pattern, which seems like a better fit for web development. That is neither here nor there because to build a webpart, you have to think like a server control developer—something I haven’t done since the ASP.NET 1.0 era.
So, my challenge is to learn the SharePoint way and also learn ASP.NET, and learn how to make things pretty. I had help on the last bit from the product group. Here is a screenshot of the basic item browser (the browser is a browser of ideas, a topic for another post):
The browser webpart is configured to browse three items at a time (this is a personalization aspect of the webpart). At the core of the browser is one method:
First, I really dislike methods that take this many parameters, but it takes a lot to feed this little algorithm:
SPList list – The list
uint pageSize – The page size (number of ideas per page)
int pageIndex – The current page index
string pagingInfo – The paging info (more on this later)
string fields – The fields to bring back from the list (in CAML)
string queryCaml – The CAML query to execute
out bool isEndOfList – An out parameter which signals that the results are the end of the list
Here is the method in context:
I get the list from the web and the default view. I pack up the fields and send the whole shebang to GetListPage. So, where does the CurrentPage and the PageInfo come from?
The key is to remember the current page’s first and last item and derive the PageInfo from that data. Lets walk through this:
1.) RenderIdeas – Capture the first and last ideas and send them along to AddNavigation
2.) AddNavigation – Use the first and last items, the list view GUID, and the current state to setup the navigation elements used for paging.
Okay, now for the code:
When the user clicks one of the links, this paging information is parsed out of the query string and feeds the next pagination call (from the OnLoad event):
That’s it folks. I hope this helps somebody because this took me about 5 hours to figure it out.