A brief discussion on native paging of DWZ table_jquery

DWZ’s native table paging is rarely used in project development recently, and third-party data binding table plug-ins such as jqgrid or grid are often used. Now if it is required in the project, you must use DWZ’s own table

Looking at a piece of code next, I will give you a detailed introduction to how to use table paging in DWZ. The following is how it is implemented in MVC.

?

currentPage="@ViewBag .currentPage">

Property Introduction

targetType: binding method, DWZ provides two methods: "navTab" and "dialog". As the name implies, it means whether the paging is on the tab page or on the pop-up layer

totalCount: total number of rows of data

numPerPage: number of data rows on the current page

pageNumShown:Total number of pages

currentPage: current page number

Copy code The code is as follows:

@using (Html.BeginForm("BidPrjList", " TbUnify", null, FormMethod.Post, new { id = "pagerForm" }))
{
 

}

Note that the paging form under DWZ must add id="pagerForm "property, otherwise it will not be executed. The essence of the paging of tables in DWZ is to pass the paging method to the backend in the form of form submission, and the backend receives the parameters and obtains the paging information: for example:

Copy code The code is as follows:

Request.Form["numPerPage"]

The value of getting the paging information form is the name of the hidden text field you define under the pagerForm form in View. After receiving it in the background, request the paging data from the data source, and then return to the front desk.

There is a small problem here: when you enter this page for the first time, the form submission event of the current paging cannot be triggered, so above I defined the dynamic assignment of ViewBag.numPerPage, how many pieces of data are divided into each page, and the front-end interface Just define the paging style, the actual data is not bound, so the paging information passed from the front desk must be used as the basis for background data paging, so that the front desk paging can be consistent with the data and will not cause confusion. This should be noted.

In the development of actual projects, we always put tables and filter conditions together. The way to pass in restriction conditions to the table in DWZ is also very simple. As above, add the hidden text field that needs to be passed in to the paging form, for example:

Copy code The code is as follows:

In this way, the incoming filter conditions can be accepted in the background.

The essence of DWZ’s table paging is to reload the data of the current tab page, causing the tab page to be refreshed. If restrictions are used together with paging, there will be a problem. After the page is reloaded, your filter conditions will be lost, and My solution here is to add a hidden text field to the paging form. Each time the filter condition is assigned a value, it will be judged in the background whether it is empty and whether to add the filter condition. I hope everyone can pay attention to this.

One final point, targetType was introduced above, indicating that the current paging method and paging are essentially the refresh of the tab page, so if we load the View layer containing the table as a partial page asynchronously, we will find that, The paging control of DWZ will not be displayed, so paging cannot be done. I have told you above that you need to specify the type for each paging. If you use $.load or @Html.Partial, you can only load the data of the first page. , this is also a flaw in DWZ. After all, the rise of DWZ has been in recent years, and there are still many problems and bugs, especially its table paging and data binding are really difficult to use, but in general, other components of DWZ are different from The style is still very good.

Okay, that’s it for today about DWZ table paging.