Application Builder

In the previous section, we talked about one primary purpose of Cliqon is the production of web sites in all their different flavours. Another primary purpose is the development of web applications. As a general rule we use the term “system builder” to describe the action of developing a web site for viewing and consumption by the general public. Whereas, we use the term “application builder” to describe the action of developing the existing administration to system to encompass an application with a limited or controlled user or operator base such as a company accounting system.

Clearly the purposes can overlap. For example Cliqon can be used for an on-line shopping system with a backend that carries out all the sales and purchase order processing.

We have already explained that Cliqon includes a comprehensive access and version control system, which are extremely important to an application. However there are many other facilities within Cliqon that make it a great tool for developing applications.


For many years, Cliqon has used a database pattern which can loosely be described as a document database. The idea behind it was inherited from Sharepoint and therefore it predates the modern NoSQL dartabases such as Mongo and Couch by some years. At the same time, we continue to believe that a traditional SQL client-server database such as MySQL or Postgres is the most reliable, inexpensive and extensible solution for storing data. Therefore the database pattern that we have used for this and the last version of Cliqon is a hybrid pattern which we believe takes the best attributes of the Document pattern but expresses them within the confines of a traditional SQL Server.

The database tables in Cliqon are defined on the basis of what type of information is stored in them and not the specific nature of the information. However we are not so bound to our own rules that when a logical and practical reason exists for having a table specific to a particular purpose, then we can and do create one. The production version of Cliqon is primarily a content management system. A system containing content that is common to all Cliqon systems (primarily involving the administration) and content that will be unique to your system or your type of system. Therefore we have just two primary tables – dbcollection and dbitem. The two tables are almost identical (dbitem supports archival version control which dbcollection does not need). Both have some columns holding structured content, that can be indexed, such as group, category, type, reference, order and parent. Both have one textual field which will hold absolutely any amount of information that you can conceive in key - value pairs in JSON (or TOML) format. This format is so flexible that one can store the content of image files and documents in their raw digitised form rather than storing them as files on the system with references to those files in the database.

As we implied we are not absolutely wedded to document storage. We do provide separate tables for Users, Logs and Session Management. When Cliqon is used to support applications that are more transaction based such as our auction or order processing and stock control, we do add a transactions table, known as dbtransaction.

Therefore we can no longer describe a database table by what it contains, such as the news, blog or menu table. We have to coin another word and for these, for that we use the concept of a Collection. Thus a Collection will consist of a number of the structural or predefined columns together with a variable number of contextual or informational fields which are frequently multi-lingual. In addition Cliqon uses the Redbean PHP ORM which taken together with our Document pattern, makes managing the data dictionary or schema a relatively trivial matter.


Cliqon has been designed to allow, permit and encourage the enhancement of existing modules, classes and methods plus the introduction new ones. We have tried to satisfy two competing objectives into the heirarchy of the sub folders and files of a Cliqon system. On the one hand we wish to provide a system where the addition of new facilities is seamless but at the same time, is separated from the existing core facilities. The problem is that we anticipate that we will upgrade core modules from time to time and our Contributors will introduce new classes and methods that on any objective viewpoint will be considered essential and core improvements to the system.

We do not suggest that we have achieved a perfect solution but we do hope that our design strategy will go sufficiently far to provide for most situations. Cliqon is designed to be used in a situation beyond the need and provision of a simple content management system and therefore will be used by serious developers who find the provision of a simple plugin system too constraining.

We anticipate that our developers will be experienced PHP and Javascript developers who appreciate the thousands of hours that have gone into the design and development and will be generally satisfied with what we have provided as a basis for their development.

Such Developers will be used to augment the source code of a web software program – primarily the PHP and Javascript. We hope and expect that they will make their alterations and additions within the heirarchy of the existing system. We will then provide a generic site update facilities that arranges to update only a certain list of files from the central repository. When a Version of Cliqon is declared as Stable, releases for this version will be extensively documented and change managed. Site Update provides the facility to “Diff” the update against current to see differences.

We see little or no requirement to update the data dictionary for the foreseeable future. We hope that we are not required to update the administrative or backend system again for some years. If you need to make changes as part of an Application build, we will do what we can to assist issues of compatibility.

We will be doing everything we can to provide adequate documentation for the system. The process of creating cook books and recipes will be on-going. The source of the documentation will be made available so that you can add your own pages.

Client server communication

To maintain state and security between client and server has been going through a quiet revolution. Traditionally, the server scripts have generated and sent a string of HTML. For a variety of reasons, this has changed. The primary reason being that the clients that initiated the communications have changed from being just desktops PCs running a web browser, to a wide variety of devices, initiating the communications such as smartphones, tablets and other internet enabled devices. In addition, only some of these devices will use a web browser to consume the communication.

For a long time, servers and web servers could send data in many forms using different protocols. For example, the stream could be formatted as XML or JSON. Cliqon has chosen to follow the general trend and enable, implement and move towards JSON.

At this moment the transition is not not complete, about 10% or traffic is sent as HTML and this is completely confined to the administration area. All communications with the Client are or can by a JSON stream. The Developer will have the opportunity to encapsulate HTML within the JSON or just send JSON data. Then the software running on the client device can be anything – a traditional web browser, an Android or MacOS application or something completely different. To support this change, we offer both traditional Session management and JSON web tokens.