A rather independent. Universal Paging Control C # source code

Page Pagination | control

Universal asp.net data paging control

For almost all data representation Web applications, it is one of the main goals to organize the way that data is displayed and to avoid confusing users. It is acceptable to display 20 records per page, but displaying 10,000 records per page can easily cause inconvenience to users. Splitting data into multiple pages is the most common way to solve such problems.

I. Overview

Asp. NET itself provides only one control that supports data paging, the DataGrid paging control, but it is better suited for use in an intranet environment, and the DataGrid paging control does not seem to provide enough functionality to construct a flexible Web application for the Internet environment. One reason is that the DataGrid control has restrictions on where the web designer places the paging control and the appearance of the paging control, for example, the DataGrid control does not allow the paging control to be placed vertically. Another control that has the advantage of paging technology is that Repeater,web developers can use the Repeater control to quickly configure the display of data, but paging functionality needs to be implemented by the developer itself. Data sources are constantly changing and data representation varies, and if you tailor the paging control to these changing conditions, it's obviously a waste of time, and building a common paging control that is not limited to a particular performance control will greatly help save time.

A good generic data control not only provides regular paging functionality, but it also allows you to:
⑴ provides "Home", "prev", "Next", "last Page" pager buttons.

⑵ adjusts its state according to the data display condition, namely has the data sensitivity. If a paging control is set to display 10 records per page, but in fact there are only 9 records, then pagination controls should not be displayed; In the case where the data is divided into multiple pages, the first page, previous page button should not be displayed, the last page "Next", "last" Buttons should not be displayed either.

⑶ cannot rely on a particular data display control.

⑷ has the ability to adapt to a variety of existing and will have data sources.

⑸ should be able to easily configure the display, easily integrated into a variety of applications.

⑹ to remind other controls when paging is ready.

⑺ even inexperienced web designers need to be able to use them without difficulty.

⑻ provides property data about pagination information.

There are already commercial controls on the market that offer the above features, but they are expensive. For many developers, building a generic paging control is the ideal choice.

Figure one shows the running interface of the common paging control in this article, where the control used for display is a repeater control. The paging control consists of two types of parts: Four navigation buttons, and a set of page number links.




Users can easily change the display control and alter the appearance of the paging control itself. For example, in figure I, display controls that collaborate with pagination controls can be replaced with a DataGrid control, with page numbering links and four navigation buttons displayed in two rows.

ASP.net supports three ways to create custom Web controls: User controls, composite controls, and custom controls. The third type of control, the name of the custom control, can easily be misunderstood. In fact, all three of these controls should be considered custom controls. The difference between a composite control and Microsoft's so-called custom control is that the former uses the CreateChildControls () method, and the CreateChildControls () method allows the control to redraw itself based on certain events. For the general pager in this article, we'll use the composite control.

The following UML sequence diagram outlines the general mechanism of a common paging control.




While our goal is to make the universal paging control independent of the controls that represent the data, it is clear that there must be some way for the paging control to access the data. Each control that inherits from the controls class provides a DataBinding event. We register the pager itself as the listener for the DataBinding event, and the pager can learn the data and modify the data. Because all controls inherited from the control class have this databinding event, the pager control achieves the goal of not relying on a particular data representation control--in other words, the pager control can bind to all controls derived from the control class. That is, it can bind to almost all Web controls.