198 Lotus blogs updated hourly. Who will post next? Home | Blogs | Search | About 
Latest 7 Posts
XPages Tip: Adding a Bootstrap Class to All Labels via the Theme (Redux)
Wed, Jul 20th 2016 7
XPages Tip: Overriding, Concatenating, and Conditionally Adding Control Properties via a Theme
Wed, Jul 20th 2016 6
XPages Tip: Displaying Bootstrap Applications Properly on Mobile Devices
Tue, May 31st 2016 8
Efficiently Keeping an XPages Session Alive with JSON RPC
Wed, May 25th 2016 6
Browser Session Lifespan – Idle Session Timeout vs LTPA Token Expiration
Tue, May 24th 2016 7
XPages Tip: Passing an Array to a Custom Control Property
Tue, Apr 12th 2016 4
XPages Tip: Beware Server-Side code in Multiple onClientLoad Events
Thu, Apr 7th 2016 5
Top 10
Gridx in XPages – 15: Adding QuickFilter for Full-Text Searching
Tue, Dec 9th 2014 12
Passing Parameters to SSJS from a Client-side partialRefreshGet()
Mon, Jul 14th 2014 11
Computing Custom Date Format Patterns Throughout an Application
Mon, Aug 18th 2014 8
Gridx in XPages – 18: Formatting Date and Currency Columns
Thu, Dec 18th 2014 8
XPages Tip: Displaying Bootstrap Applications Properly on Mobile Devices
Tue, May 31st 2016 8
XPages Tip: Setting the Body Class
Wed, Nov 26th 2014 7
Browser Session Lifespan – Idle Session Timeout vs LTPA Token Expiration
Tue, May 24th 2016 7
XPages Tip: Adding a Bootstrap Class to All Labels via the Theme (Redux)
Wed, Jul 20th 2016 7
Dojo in XPages – 20: Handling Successful or Failed AJAX Requests
Wed, Apr 23rd 2014 6
Book Review – Mastering XPages, Second Edition
Tue, Jun 3rd 2014 6

Gridx in XPages – 4: Loading Live Data via a REST Service
Twitter Google+ Facebook LinkedIn Addthis Email Gmail Flipboard Reddit Tumblr WhatsApp StumbleUpon Yammer Evernote Delicious
Brad Balassaitis    

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.

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:viewJsonService defaultColumns="true" viewName="ByName-First" var="dataRow">

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):

  "address":"392 Shinn Street",
  "city":"New York",
  "address":"392 Shinn Street",
  "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. 

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.

Gridx 4 - Grid

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.

Nov 10, 2014
4 hits

Recent Blog Posts

Created and Maintained by Yancy Lent - About - Planet Lotus Blog - Advertising - Mobile Edition