Wednesday, 16 October 2019

JET - using non-Oracle REST with common model

JET - v7.2.0
Source: {
  "front-end": jet-with-custom-rest,
  "server": test-server

We are so much used to building Oracle JET applications with ADF BC REST services. It is true that JET is developed quickest if you use an Oracle standard REST service (such as ADF BC). But it is also true that JET's common model architecture does support REST end-points which do not conform to Oracle standards.

Let's see an example. An Oracle standard REST sends response in the following format:

With these information available in the response, we assume that JET will take care of parsing the data and show a paginated table. This is true. If data, even if from a non-Oracle REST, is presented to JET in this format, we do not have to write any extra code to display the same on the UI.

But what if the data comes in this format (and that too from a POST request):

In this case, we have to extend some of the nice hooks provided by JET API to ensure that the new data format is understood by JET. Let's see how. For demonstration purposes, I am using a simple NodeJS express API.

The common model architecture uses two layers of data modelling - the oj.Model and the oj.Collection. The model represents a single row (or object), and is the blue-print of your data structure. The collection is simply an aggregate of models.

Both the model and the collection have a parse property each, which takes in a function. The collection's parse function takes in the entire raw response as a parameter. It is here that we would tell JET where to look for our data array. This is fired only once.

And in the parse function of the model, we get each item of the data array specified by the collection's parse method above, and it is here we tell model where to look for each row's attributes. This is fired for each item of the data array.

Now to support a custom POST end-point as the source of data, we need to set a function as a customURL for the collection. In this custom-url, we can set various options for the REST end-point that we intend to hit for data.

We're almost done. Before we wrap up, we use the total and pageSize values from the response into a customPagingOptions function.

For pagination, we need the total-count (totalResults) and page-size (limit). If offset is not available then it can be calculated from page as (page * pageSize). Or page may be calculated from offset as (offset / pageSize). It all depends on what parameter is understood by the REST from which we are fetching data. In my case, I am sending the page value.

We are all set up. Run ojet serve and we get this:


1 comment: