Gridx in XPages – 4: Loading Live Data via a REST Service

In the last post, I showed how to get a simple Gridx grid up and running in an XPages application with hard-coded data. In this post, I’ll show how to load live data via a REST service, which requires a different type of data store and cache.

Gridx Series

Gridx in XPages — Entire Series

Providing the Data via a REST Service

My test application uses a subset of data from the Fakenames.nsf database from David Leedy’s XPages Cheatsheet.

I created an XPage named X_REST and added a viewJsonService REST service to surface data from the ByName-First view.

<xe:restService id="restJsonService" pathInfo="gridData">
  <xe:this.service>
    <xe:viewJsonService defaultColumns="true" viewName="ByName-First" var="dataRow">
    </xe:viewJsonService>
  </xe:this.service>
</xe:restService> 

The defaultColumns attribute is set to true, so it will automatically include all columns from the view in the output.

The pathInfo attribute is set to gridData, so I can reference the REST service from within the application via this URL: X_REST.xsp/gridData

Here’s a sample of the REST service output (the first row from the view):

{
  "@entryid":"1-4030FB42B37B397785257D87004680BC",
  "@unid":"4030FB42B37B397785257D87004680BC",
  "@noteid":"FCE",
  "@position":"1",
  "@siblings":1298,
  "@form":"fUserName",
  "firstname":"Adam",
  "lastname":"Gonzales",
  "address":"392 Shinn Street",
  "city":"New York",
  "state":"IL",
  "zip":10021,
  "country":"US",
  "address":"392 Shinn Street",
  "password":"nae1nae7Su",
  "phone":"212-774-8218",
  "mothersmaiden":"Shah",
  "birthday":"1952-02-08T11:53:39Z",
  "cctype":"MasterCard",
  "ccnumber":5436047424022667,
  "cvv2":830,
  "ccexpires":"2\/2009",
  "national":"051-68-8261",
  "ups":"1Z 82F 8A5 82 1526 912 5",
  "occupation":"Substance abuse and behavioral disorder counselor"
}

All of the attributes beginning with @ are system columns that are automatically included. (You can refine which system columns are included via the systemColumns attribute of the REST service.)

The rest of the attributes are based on columns in the view.

Updated Gridx Using Live Data

In order to use live data, there are two primary changes to make to the grid code:

1. Data Store
2. Cache

Rather than using a Memory store, it changes to a JsonRest store. This includes the ability to retrieve remote data.

Since it is now using remote data (rather than hard-coded local data), we also switch the cache from synchronous to asynchronous. All you have to do is load a different cache module — no other code needs to change.

<script> require([
  "gridx/Grid", "dojo/store/JsonRest",
  "gridx/core/model/cache/Async", "dojo/domReady!"
  ], function(Grid, JsonRest, Cache) {
	  	
  var store = new JsonRest({
    idProperty: '@noteid',
    target: "X_REST.xsp/gridData"
  });
		
  var columns = [
    {id: 'first', field: 'firstname', name: 'First', width: '70px'},
    {id: 'last', field: 'lastname', name: 'Last'},
    {id: 'state', field: 'state', name: 'State', width: '40px'}
  ];
	
  grid = new Grid({ 
    id: "my_gridX", 
    cacheClass: Cache, 
    store: store, 
    structure: columns 
  });
			
  //Put it into the DOM tree. 
  grid.placeAt('gridX_Here');
  grid.startup();
	  
});
</script>

Lines 1-4 define our updated AMD loading requirements. The data store is now dojo/store/JsonRest and the cache is now gridx/core/model/cache/Async.

Lines 6-9 set up the new JsonRest store. The target attribute specifies the URL where the REST data can be retrieved. (I’ll come back to the idProperty attribute momentarily.)

Lines 11-15 define the columns for the grid. The field attribute of each column must match up with an attribute name in the REST data. In this case, it’s set up to show the first name, last name, and state columns from the underlying view.

Lines 16-25 define the Gridx object and instantiate it. None of these lines changed since the first simple example.

Using this code, we now have a Gridx grid that displays live data from our application.

Define the Unique ID

I want to call attention to line 7 in the source code above — the idProperty attribute of the JsonRest store.

Gridx requires that each row have a unique identifier. It assumes that it will find an attribute named id in each row. However, the ByName-First view does not have a unique ID column named id. This causes the grid to display data from the last row repeatedly in place of each row in the grid (presumably because all rows have no known id and, therefore, cannot be differentiated.)

The simple solution to this is to set the idProperty attribute of the store. This lets the store know how to uniquely identify each row and it allows the grid to display the data properly. I used the @noteid attribute in the example above, but you could also use @entryid, @unid, or even @position.

Data Requests

It’s interesting to note that (without me doing any configuration) the grid makes two GET calls as the page loads.

It initially loads the first 99 rows, presumably to let the grid load faster.

It then makes a second call to get the rest of the data from row 100 on. (At this point, my example has about 1300 rows. I don’t know at this point if it will break very large data sets into multiple additional calls.)

Gridx touts performance and its ability to handle large data sets. I would assume this means that it’s doing its best to both load quickly and still get the full data set locally for fast processing.

When the grid loads, I have the ability to quickly scroll through all rows.