Defining A Block

Every block defined in a coServ app has several properties. When you create a new block, you have to specify those properties so coServ knows how to work with the new block.

Below are the possible properties of a block:

• block path: The URL or endpoint of the block.

• title: Title of a block. When a block behaves as the main block (the block which provides the major contents of a page), its title will become the page title.

• description: Description of a block. Similar to the title property, when a block is served as the main block, its description will become the page description (shown in the <meta> tag).

• id: Does the block endpoint contain ID? This property can have only three possible values: "yes", "no" and "maybe".

• service: If the data model of a block is served by a remote API service, the service endpoint should be specified here.

• isProtected: If the page is protected against unauthorized access. For example, if the block can only be accessed by logged in users, this property should be set to true. When set to true, any unauthorized access will be redirected to the app login page.

Block settings are specified in the "siteURI.json" file. You can manually edit the file to do the setting. You can also use the design console as that would probably be easier.

If you manually edit the "siteURI.json" file, please note that the "block path" is the key of the key/value pair of that file.

If you use the design console to do the setting, you can choose the block and then click on the "config" tab.

Specifying block input

As explained earlier, a block is a HTML fragment so it will inherit any problems that HTML may have. One of the problem is, there is no way to explicitly or formally define input of a page. When an app grows bigger and has more and more pages, just to know what are the page input could be a headache.

As a platform to harness HTML, coServ has a solution for it. For each block, you can explicitly specify its input in the block configuration. The specification would be like:

"query": {
    "param1": {
        "type": "string",
        "required": true,
    },
    "param2": {
        "type": "num",
        "required": false,
        "default": 20
    }
}

"type" is the data type of the parameter. It could be "string", "num", "bool" and "object". Other properties are self-explanatory.

The block input is specified in the "siteURI.json" file. Again, you can manually edit the file or use the design console to describe the block input.

The current release does not enforce the input parameter check. So if you do not specify input parameters for a block, things would still work. However, if you do make the specification, it will make your app more readable and manageable.