coServ Tutorial Part III

Ben Lue
5 min readJun 2, 2019

If you’ve done with the first two parts, you should have been able to create a coServ web app and write simple palets of your own. In this third installment, we’ll dig deeper into the MVC constructs of a palet.

In the previous tutorial, we’re trying to use a modal dialog to show the detailed properties of a TODO item. However, that feature was not completed yet because we haven’t shown how to access the data model from a client side controller.

In this tutorial, we’ll show how is that possible. To do so, we need to know more about the exported functions of a palet module. Let’s start with the request process pipeline.

The request process pipeline

A palet is a miniature of a web page. To make web app development a less complicated task, coServ applies the MVC design pattern and help programmers to specify the model-view-control trio in a single node module.

How are the MVC model applied when a user request comes in? The following diagram depicts the request process pipeline undertaken in coServ.

When a user request comes in, coServ will parse the request URL and decide which palet will take on the request. During the process, these functions or object of the palet will be executed:

  • checkIn: This is a Javascript object defining what are the input parameters to a palet.
  • model(): This function is to generate the data model of a palet.
  • view(): This is the HTML rendering function. The palet specific CSS can be declared here, too.
  • control(): This function defines the UI controller of a palet. Even though it’s defined in the same module with the model() and view() functions, the control() function is actually executed on browsers, not on servers (coServ will do the magic for you).

As shown in the above diagram, the pipeline sequence is URL parsing, input parameters checking, model generation and view rendering. The input data will be fed to the model() function, and the data model generated will be fed to the view() function.

The data model

The palet data model is generated by the model() function. Below is its signature:

exports.model = function(inData, ctx, cb)

The first argument is the input from HTTP requests. Assuming a request URL is something like /user/setProfile?name=David&age=38, the inData parameter will be:

{
"name": "David",
"age": 38
}

The second argument is a context variable compiled by coServ. The context variable is an object in itself and has the following properties:

  • id: the palet ID. A palet ID is the ID attribute of the palet’s HTML root element.
  • title: the title of a palet.
  • cookies: the HTTP cookies sent along with the client request.
  • locale: the locale to which a palet view should be renedered into.

There are more properties in a context variable than shown above. To keep the tutorial simple, we just introduce the important ones.

The third argument to the model() function is a callback function. The callback function is required because data model generation could be asynchronous. For example, you may query a database or an API server. The callback function expects a single parameter with the following properties:

  • code: the result code. If the data model is successfully generated, 0 should be returned. Any non-zero number indicates an error.
  • message: the text version of the result code.
  • value: set the actual data model here.

View generation

The signature of the view generation function is:

exports.view = function(model, cox)

The first argument model is the exact one returned by callback function of exports.model(). The second argument ctx is the same as the ctx context variable mentioned above in the data model section.

In exports.view(), you should return a HTML element as the root element of a palet. The root element along with its descendents make up a palet’s view.

The UI controller

Inside a palet, you can define UI control functions. That’s done by the builder function. Below is the function signature:

exports.control = function(p, model, ctx)

The first argument p is the palet instance. You should define your control functions on p. The following example shows an event handler click() is defined on a palet instance p:

exports.control = function(p) {  p.click = function()  {
alert('Ouch!')
}
}

The second argument is the data model of a palet, and the third argument is a context variable. Those two arguments have the same content and meaning as those of the export.view() fucntion.

Access the data model on clients

With the signatures of the model, view and control functions of a palet explained, we can now finish the TODO list example.

Let’s review the controller function done in part II of the tutorial:

The code above turns on a modal dialog, but that dialog does not present the detailed properties of a selected TODO item. Let’s modify it a bit to work as we want:

The differences are in line #8 ~ #10. In line #8 a palet “/todo/view” is set as the body of the todoModal dialog. The “/todo/view” palet can display all the properties of a TODO item, but it needs those properties. The data model of a selected TODO item is accessed via the model argument. Let’s highlight the code again:

model.list[itemIndex]

The running sequences of TODO items are stored in the “data-index” HTML attribute, and we retrieve that index in line #5 (itemIndex = li.dat(‘index’)). The data model of a palet can be accessed via the second argument of the exports.control() function as we’ve explained earlier. Now with the data model and index of the selected item ready, we’re able to retrieve the detailed information of the selected item. Below is the snapshot:

Great! This should complete our tutorial. If you think something is not properly explained in the tutorial, feel free to add your comments or feedback below.

--

--

Ben Lue

CEO of Gocharm Inc. and father of two amazing children. Love programming since teen and still loving it.