Even though we parameterized the query for Artists in the last step, it could still return a large number of entities depending on the data in question. RIA provides a means to handle this via the DataPager control and what Brad Abrahms calls “connect-the-dots” data binding. I wanted to do the same for the artists query, but I wanted to also keep the view neat, so I began with a slight layout tweak to the layout. In the Grid that contains the artistDataGrid, I added an additional auto-sized row for a DataPager as shown:

image

When I looked, the DataPager wasn’t there in my toolbox, so I added it via right-clicking, selecting “Choose Items…” from the context menu, and then checking it in the list of Silverlight Components.

image

With the DataPager now in the toolbox, I dropped it on the design surface in the neighborhood of where I wanted it to appear. This can get a little tricky with auto-sized rows, so I adjusted the XAML to get it in Grid.Row=”2” with nothing else set as shown:

image

The DataPager needs to know what size pages we’d like, so I set the PageSize property to something I thought was reasonable (i.e., 10.) Then, to “connect the dots”, I dragged the GetArtistsByName query on to the DataPager, which added the following binding to the DataPager’s XAML:

image

The artistDomainDataSource’s Data is the “dot” that needed to be “connected” in order to make the artistDataGrid work with dataPager1 as expected. I ran the app and got what I was hoping to see – a master-details-details UI with a place to input query parameters and with pagination at the master level.

image

The column sorting at the master level even worked as I think most people would expect. Sorting by name sorted the entire (3 page) set and not just the local batch of 10 in the current page.

image

Since I had a reasonably functional app running, I wanted to do some simple styling to improve its UX a bit. That will be the topic of the next post. In the meantime, code for post is here.