A set of embedded or independently used paging controls: WebPager (with source code)

Everyone should be familiar with the pages control in ASP. NET, and there are many such examples on the Internet. I have also done many types of such controls, but the design philosophy is not the same. In terms of functions, one is to present only the appearance and operations required for page turning, and the other is to wrap the paging function for data at the same time. In terms of form, there are (embedded) extended DataGrid page flip functions, but also independent page flip functions.
My purpose for this set of WebPager is to take into account all the above aspects and make a flexible and scalable paging control. That is to say, it can be embedded into the DataGrid and used independently. At the same time, it is better for me to easily switch the page flip style or appearance without changing the class or interface.

Appearance

It is not difficult to achieve this goal. We had to inherit the DataGrid class, and then rewrite the part that generates and controls page flip.

Public sealed class AdvDataGrid: DataGrid {
Public AdvDataGrid (){
This. ItemCreated + = new DataGridItemEventHandler (AdvDataGrid_ItemCreated );
}
 
Private void AdvDataGrid_ItemCreated (object sender, System. Web. UI. WebControls. DataGridItemEventArgs e ){
If (e. Item. ItemType = ListItemType. Pager ){
Literal msg = new Literal ();
Msg. Text = "replace the three statements with the code that shows the actual page flip control. ";
(TableCell) e. Item. Controls [0]). Controls. Add (msg );
}
}
}
To reuse the paging sub-control, you can use it independently and embed it. You only need to extract the code and place it in an independent class. Here, we extract the public interface IDataPager for all flip child controls. The code in the ItemCreated event should be changed:
IDataPager pager = DataPagerFactory. CreateDataPager ("SimplePager ");
(TableCell) e. Item. Controls [0]). Controls. Add (pager );
Here we will stop and look at the benefits of doing so. First, the paging code is put into an independent class, which helps reuse (to prepare for the independent use of the paging control). Secondly, because public interfaces are extracted, all classes that implement this interface can be loaded into the DataGrid as page flip sub-controls to achieve diversification. Third, create a specific page flip sub-control in factory mode, you can easily switch the appearance.

Here we only implement the embedded DataGrid. What if DataList is used? It doesn't matter. In the ItemCreated event, rewrite the appearance. DataList does not support page turning. There is no ItemType = ListItemType. Pager? It doesn't matter. We can load the paging subcontrol In the Footer part of DataList.
Here we implement two tabs sub-control containers, DataGrid and DataList. Let's see what they have in common. First, we need paging information, such as the current page, page size, and total records. This class has been encapsulated in PagerInfo. All containers must have such an attribute. Second, we need to be able to change the type of Pager used by this container at any time by modifying PagerClass. This should also be done in attributes. There are also the events triggered when pages are turned on. This is also essential.
Here we will extract another interface: IDataPagerContainer for the container class of the flip child control. All containers that can load the paging control must implement this interface.
In this way, our WebPager class structure is basically formed. The IDataPager interface extends various paging subcontrols. The IDataPagerContainer interface extends a variety of containers. They can be freely attached and combined.

The last problem persists. The flip control is used independently. This is also relatively simple. All paging controls have the PagerInfo attribute, which describes the current page information. When the page changes, its PagerInfo. PageIndex also changes. Then we can obtain different data based on this, and then bind the data display control.
Here I was going to make the paging sub-control to run and display completely independently. That is to say, they can be dragged to the page. However, it was later found that the implementation was not very beautiful and the original structure was abandoned. Therefore, the independent use of sub-controls still relies on a third-party container: DataPagerContainer. This is a general and simple implementation of the IDataPagerContainer interface. In this way, you can easily change the appearance when using the flip control independently.
Class Structure:
Hooyee. Utils. PagerInfo encapsulate data paging information. Such as PageSize and PageIndex
Hooyee. WebControls. IDataPagerContainer public support interface for the container object of the page flip control.
The container class for Hooyee. WebControls. DataPagerContainer generic data paging controls. It can be used as the default container.
Hooyee. WebControls. AdvDataGrid supports the DataGrid of the page flip Control
Hooyee. WebControls. AdvDataList supports DataList of the paging control.
Hooyee. WebControls. IDataPager implements the public interface of the user control for data paging.
Hooyee. WebControls. DataPagerBase is a public abstract base class for user controls that implement data paging.
Hooyee. WebControls. FirstPager: a specific page flip sub-control implementation.
Hooyee. WebControls. SecondPager is a specific page flip sub-control implementation.

Download