Showing posts with label 7.2.0. Show all posts
Showing posts with label 7.2.0. Show all posts

Wednesday, 25 March 2020

JET - show global processing icon

JET - v7.2.0
Source: GitHub

This is a quick demonstration on how to setup an application wide processing icon, which may be displayed every time a lengthy operation is in progress, and you don't want the user to perform anything else in the meantime.

JET provides a useful component - oj-progress - which may be used effectively for this purpose. This, along with some nice CSS tricks for creating an overlay, can solve our problem.


The oj-progress component is displayed on some boolean condition being set to true, and is hidden when the condition is set to false.

The component is placed at the root of the application, in index.html, so that it may be accessible to all child modules. The control is in appController.js, which is registered with the window object, so that the module may be accessed by any component, without the need to explicitly load it in the define block.



Cheers!

Tuesday, 17 March 2020

JET - with mongodb, nodejs and express

JET - v7.2.0

We all talk about the MEAN stack and the MERN stack. What about a MongoDB-Express-Nodejs-Jet stack this time? Can we call it the MENJ stack? I started on a POC and ended up on a full-blown cloud implementation of the stack. Sharing the POC results below.

Test users: refer to README.

Source code:
Oracle JET: (GitHub) hr-store
Node/Express: (GitHub) hr-server

The location/department/employee objects have been made similar to those from the HR schema, including the master child relationships. The master-detail page in the JET app implements this relationship.

Since I wrote my own middleware, I had the freedom of customizing the REST data to a standard easily suited to JET. However, I did have to extend the JET framework to support custom URL call and pagination.

This blog post may help you further to understand the master-child and search model implemented in this POC.








The front-end JET code has been deployed on heroku server. The Node/Express middleware is running on another heroku instance. You may access and play around with the deployed instance @ https://menj-stack.herokuapp.com/

Disclaimer: since the front-end, middleware and database are all running in 3 different servers, the performance of the deployed instance is quite disappointing. But hopefully it will let you gain some amount of insight with the stack.

Cheers!

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:


Cheers!