Getting started with Oracle JET: a CRUD service

Bram Kaashoek
0 0
Read Time:3 Minute, 2 Second

Introduction

AMIS has recently set up a brand new Enterprise Web Application team, of which I am proud to be a member. We will working in front-end development using a variety of Javascript based frameworks. As a first framework, we are currently investigating Oracle JET.  After working through the Oracle JET MOOC and a Knockout.js tutorial we have begun to build a meetings organisation app in order to get some more hands-on experience. This app is initially intended to have users and meetings, allowing for the users to create, show, update and delete meetings with their authorization dependent on authentication. This blog post is intended to show you some of the discoveries we made while working on this project.

Getting started

To keep things simple, we started of by setting up a FeathersJS REST API as a back-end with two models, one for meetings and one for users, as well as some seeds to provide initial data for these models. The next step was to make this data available in the JET app, across any of the components which might want to make use of it. This was done through use of the JET model and collection systems. In this system an model is a single data record, while a collection contains multiple records.  Since we want the CRUD functionality to be available to different JET components, we placed the code in a separate service as shown below. As you can see, this service defines the model and collection as well as providing an instance of the collection. The parseMeeting and parseSaveMeeting functions and attributes are optional and can be left out if you do not want to change the names of any attributes from back-end to front-end. The comparator attribute of the collection is used to order the different models.

CRUD actions

After setting up the model and collection, we added  CRUD functionality. JET models and collections provide functions which take care of the communication with the back-end. For example, when using the create function a plain old javascript object can be passed, as well as success and error handlers. The collection which was instantiated earlier is used to call the create function on, adding the new model to collection for quick availability in the front-end as well as making a call to the back-end to create the object in the database. Specific headers can be used, for example in order to pass an authorization token.

For the fetch and delete methods, we instantiate a new model and set its ID to the ID of the object we want to affect. The relevant function is then called on this object. In the case of the fetch function, the data in the model is mapped to a plain old javascript object, which is returned. In the success handler of the delete function we remove the destroyed meeting from the collection, automatically updating all components in the front-end which rely on its data. The update function accepts both  plain javascript objects and JET models.

Calling the service

Setting the service up like this gave us an easy to use way to interact with our back-end, as well as allowing us to clean up the code of our components and remove any duplication. Here is an example of how we call this service from our meetings.js. Other services can be set up in the same way, or multiple services could even inherit from the same base service.

 

Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %
Next Post

Setting up Oracle Event Hub (Apache Kafka) Cloud Service and Pub & Sub from local Node Kafka client

Oracle offers an Event Bus Cloud Service – an enterprise grade Apache Kafka instance – with large numbers of partitions and topics, (retained) messages and distributed nodes. Setting up this cloud service is simple enough – especially once you know what to do, as I will demonstrate in this article. […]
%d bloggers like this: