See also: Paging records using a Form element
There are several reasons why we want to do paging in the UI, like Performance and Usability. There are also several strategies as to Where to do the paging. In this example we do the following:
- Get all the records from the Data Service (Backend).
- For each user press run a filter on the data to show in the UI the relevant part.
Prerequisite – row number:
- We depend on the row number to exist in the Data Service out port. This seems harsh, but should be easy to achieve for example in an SQL Query.
- In case we can’t get it from the Data Service, we could write our own Web Service to add this to the data. See in Paging Records in the UI – using our own Web Service to get Row Numbers.
After pressing Show Data:
Showing the last page:
1. Consume the required Data Service.
2. Add a Data Share and connect the Service output to it.
3. Add a Data Share to contain the current records index and the step (jump) for each Next press.
4. Add an Aggregate Operator to compute the number of records returned. We need to know the number of records to disable the Next button when reaching the last “page”.
5. Filter the results when catching the ‘update’ event – we will soon model its triggering. Here we filter to show the results of the current step, for example – records 1 to 4 as seen in the runtime snapshot above:
6. In the output table add a button (Show Data) in the Toolbar for showing the first records:
– Add an Assign Action to reset the index value
– Trigger the “update” event (Custom Action) to run the filter.
7. Add another button (Next) to perform two actions:
– The Assign Action to update the global index of presented records to the next step.
– Trigger the “update” event to rerun the Filter.
8. Do the same with the Previous button, only here we subtract the step size:
9. Edit the Enabled condition of the Previous and Next buttons: