Introduction
This is intended to be a complete user guide of the coServ web server.
Why coServ
It's simple. If you don't want to spend time on learning and trying to work with a platform to get your job done, you should think about coServ. coServ is not opinionated, so you can use (almost) any front-end and backend libraries. Unlike many web platforms which device thier own directives and schemes, coServ uses HTML/CSS/Javascript and requires nothing more. Even the back-end programming is done by Javascript (node.js).
If you want just a few words to convince you, here your are:
Beyond HTML, CSS and Javascript, you have nothing new to learn to write a great app. coServ helps you to easily harness them.
coServ makes HTML refactoring possible.
Transparent CSS encapsulation. CSS encapsulation is automatic on coServ and developers do not have to do anything to make that happen.
Terminologies
We'll start with some terminologies which could help to identify the core concepts of coServ.
Websites
A single coServ server can host multiple websites. Each website is assigned a web domain or an IP address. Each website also has a code name as its idenfifier.
For a website to be presentable, it should be assigned with a web theme. A web theme decides the look and feel of a website.
Web Themes
A web theme usually has several page layouts defined. Each page layout can be applied to a group of web pages. In a page layout, the placement of "top level" blocks (such as the page header, page footer and the page body) is specified.
Blocks
Blocks are the core concept of coServ. A block is a HTML fragment which is self-contained. Typical examples of blocks can be page menus, page headers or page footers. On coServ, web pages are composed of blocks and each block can further be composed of smaller blocks.
In terms of its structure, a block has three parts: model (contents), view and controller. A block view is manifested with a HTML file. An additional CSS file and a multi-lingual resource file can also be supplied to make up a block view.
A block controller is implemented by a Javascript file. The block controller is not required, meaning you can implement a block without a controller.
A block model is usually a node.js module to manage (query or update) contents of a block. You can also use API services to implement the block models. Block models are also optional. It's quite possible to implement a block without any data model at all.
Wcomps
Conceptually, wcomps are very similar to web components except that wcomps do not use shadow DOM and do not require polyfill or native support from browsers. Wcomps are also similar to blocks. The main difference between wcomps and blocks is that wcomps are not bound to any specific contents (data models). In other words, only views and controllers are specified in wcomps.
With wcomps, you can package sophisticated UI designs into a component which is ready to be re-used anywhere in your web applications.