This project is read-only.

Pager

This control needs reference to MVCControlToolkit.Controls.Core-x.x.x.js.

There are three pager helpers:

  1. Submit Pager that performs a submit (Ajax or normal) in the form it is in and it is better suited for data editing purposes, 
  2. Get Pager that performs a simple get (Ajax or normal) to a completely configurable route, and it is better suited for REST displaying of data.
  3. Client Pager All its buttons are not rendered by the server, but they are created and modified dynamically on the client side each time the page changes. It triggers a javascript event when the page changes, but it can optionally cause a form submit. Since it doesn't need the server to render its buttons it is well suited for paging data to be retrieved through ajax calls that returns json data, or for paging local javascript data.

Mvc Controls Toolkit pagers, essentially handle adequately an integer property of the View Model containing the current page of some data that are currently displayed.

Its buttons and page links have the only effect of modifying this property, and performing a either submit or a get to a configurable Route(according to which overload is used). Then, it is up to the Controller to handle properly the actual data.

There are buttons for the first, netx, previous, and last page and a component containing directly the page links. For the last one the user can choose how many page links to show. Links and buttons appear enabled or disabled adequately. If the user supplies also a Total Count of the pages it will be used properly in enabling/disabling buttons and links, however it is not obligatory.

Each component can be rendered separately and one can decide if using it or not. Thus, you can decide to use just next or previous page buttons or just the page links, or a mix of the two....Whatever you want!

Each button can be displayed either as a normal button or as a link or as an image link. Select the one you prefer by using the PageButtonStyle enumeration.

If you supply also a Previous Page field the Pager will just mantain its value when the View is posted. It is useful on the server side to know on what page possible modifications(deletion, modification or insert) were done. However this parameter is not compulsory.

Submit Pager

Below an example of use of the  submit causing pager helper:

 

@{ var pager = Html.PagerFor(m => m.Page, m => m.PrevPage, m => m.TotalPages); }
                    
@pager.PageButton("<<", PageButtonType.First, PageButtonStyle.Link) 
@pager.PageButton("<", PageButtonType.Previous, PageButtonStyle.Link)
@pager.PageChoice(4, pageNames: p => string.Format("({0})", p))
@pager.PageButton(">", PageButtonType.Next, PageButtonStyle.Link) 
@pager.PageButton(">>", PageButtonType.Last, PageButtonStyle.Link)
                    
@pager.PageButton("Go To", PageButtonType.GoTo, PageButtonStyle.Button) @pager.GoToText(new {style="width:50px;" })

 

It is applied to the same example of the DataGrid that is here. You can find both examples in the binary distribution. For a complete example application see here.

Please notice the pageNames: parameter that allows the  user to provide a function that transfrorms page numbers into strings. In the example above it is used just to put '()' around the page numbers, but it can be used also to implement a  dictionary type of  paging. That is, a paging based on the first characters of a string that someway represents the record(for instance all customers whose surname starts with 'A'). Disabled buttons are applied the attribute disabled="disabled" as usual for disabled elements. The current page is applied the attribute: selected-page="selected". Both can be used to create CSS rules for styling the involved nodes. Please notice that all browsers, already apply some standard styling to all disable input fields, while internet explorer apply such a style, not only to input fileds and buttons, but also to all other disabled DOM nodes, such as images, and links.

Get Pager

The get causing helper works in a similar way. Only the first of the above instruction change:

 

 public static Pager<VM> Pager<VM>(
           this HtmlHelper<VM> htmlHelper, int currPage,
           string parameterName, 
           string actionName,
           int? totPages = null,
           string targetIdName = "",
           string controllerName = null,
           object otherParameters = null,
           string routeName = null,
           string protocol = null,
           string hostname = null,
           string fragment = null)

 

Where:

  • currPage is the current page
  • parameterName is the Route parameter name where to put the page number of the various links
  • totPages, is the opttional count of the total pages
  • targetIdName is the id of an html element to use as atrget for an ajax call. If it is provided the pager will do an ajax call instead of a normal get
  • otherParameters is an anonymous object containing all other parameters for the Route.
  • All other parameters define the Route as in an Action Link.

Client Pager

There are two overload of the client pager:

 

        public static ClientPager<VM>  ClientPagerFor<VM>(
           this HtmlHelper<VM> htmlHelper,
           Expression<Func<VM, int>> page,
           Expression<Func<VM, int>> totPages=null,
           string pagePrefix=null, string pagePostfix=null,
           bool causeSubmit=false)

 

Where:

  • page is an expression  locating the page property within the ViewModel
  • totPages is an optional expression locating a property containing the total pages within the ViewModel
  • pagePrefix and pagePostfix are optional strings that are prefixed and postfixed to the page number
  • causeSubmit when true causes the submit of the form that contains the pager when a page change occurs. It is useful mainly to trigger ajax calls tht return json data, instead of returning html.

If the pager is rendered within a Client Block both the page and total pages properties of the Client Side ViewModel are bound to the pager with adequate knockout bindings . This way each time they change the appearence of the pager changes immediately to reflect the new values.

 

Each time the page changes the pager triggers an event:

 

trigger("queryChanged", data);

 

where the data object contains the following fields:

  • type, specifies the kind of query information that changed. For the pager its value is the string: 'page'.
  • submit, by setting this value to true within our event handler we can cause a form submit. By setting it to false we prevent a form submit.  The value passed initially in this field is the causeSubmit  of the pager helper.
  • page, the current page.
  • previousPage: the previous page.
  • totalPages, the total pages, if available.

The event bubbles through the ancestors chain, so we can specify an event handler in any DOM ancestor of the pager.

The second overload of the pager doesn't use expressions, but fileds names and values (as for TextBox instead of TextBoxFor) :

 

public static ClientPager<VM> ClientPager<VM> (
           this HtmlHelper<VM> htmlHelper,
           string pagerName,
           int initialPage=1,
           string totalPagesName=null,
           int ? totalPages=null,
           string pagePrefix = null,
           string pagePostfix = null,
           bool causeSubmit=false)

 

where:

  • pagerName, is the name of the property containing the current page
  • initialPage is the page initially displayed by the pager 
  • totalPagesName is the name of the property containing the total pages
  • totalPages is the initial value of the total pages.
  • all other parameters are the same as the ones of the other overload

Last edited Jun 22, 2014 at 11:52 AM by frankabbruzzese, version 28

Comments

No comments yet.