The Documentation for Cliqon is divided into a number of sections. Each section is an item at the root of the documentation tree.

Installation

The section on Installation provides explanation and help about the automated installation process which guides you through the basic steps of installing a Cliqon system. If there are some reasons why the wizard cannot be used, the Section also contains a series of pages explaining how to setup the system manually.

Configuration

The section on Configuration describes in detail all the standard configuration values for a default Cliqon system. It explains how these values are mostly stored in TOML format in either text files on the server or as textual entries in the database.


The section describes the Cliqon TOML format. It describes how the configuration values are used to manage the inputs and outputs of the system including forms, displays and reports. It explains how to tune existing values for your own needs and how to create new files and database values for your own development needs.

Administration

The Administration system of a Cliqon internet system will serve one or both of two functions. If the toolset has been used to create a presentational website, then the owners and operators of the website will use the administration modules to create and maintain the content of the website. If the Cliqon system has been used to create an intranet type system such as a project management or CRM system, the enhanced administration system may be the complete application in itself. Finally Cliqon may have been used to build a combined system such as an eCommerce website consisting of on-line catalogue, cart and order processing module, in this case the administration module will be enhanced to offer all the necessary functions.


The Administration section of the documentation will explain all the functions of the standard Cliqon system  in terms of what administrative processes are supported – the ability to enter data and content into the database, the ability to process that data for different purposes (usually associated with the use of Cliqon as an application – for example: eCommerce, CRM or Auction), and view the processed data in a format that is appropriate to the type of data – images in a gallery, data in a table or grid, locations and menus in a tree format and events in a calendar format.


The section will explain how to import and export data, how to configure a grid or list, how to design forms and reports,  how to create and maintain languages, how to create menus, how to convert configuration files into values held in the database, the caching and logging system, how to maintain an online help system, how to use the portal system for useful links, news articles, blog and events, plus a series of pages explaining the administration utilities such as system update, site map, data dictionary and language strings used in the javascript.


How to develop your own administration modules is covered in System Build.

MVC Framework

The use of the wording Model – View – Controller (or its acronym MVC) is a much interpreted definition. We describe Cliqon as a MVC framework as it has Models for the data, Controllers to start the processes and the possibility for several Views subdirectories. We use the plural of subdirectory because Cliqon needs to support more than one Views subdirectory because the Admin system is a View and has its own heirarchy of subdirecties such as CSS, Javascript, Components and Partials.

Folder structure

We hope that the heirarchical subdirectory system that we have chosen for Cliqon is intuitive and straightforward. The installation wizard checks that the folder structure is correct and warns of any missing subdirecties or incorrect folder permissions.

Routing – Controllers

The use of .htaccess or web.config files is not essential to the operation of the system but are advised for reasons of security. The appendices contain notes about installing Cliqon on webservers with different Control Panels. A good example is CentOS Webpanel which needs a particular setup of folders and permissions and our installtion notes are provided for that purpose.


Cliqon Framework supports a RegEx Router. The Routes are configured as a TOML array. The Router interrogates the routes configuration and hands off serving the URL to a suitable Controller as configured in the Routes file. The Router and Controller can differentiate between different types of Request protocol – GET, GET_XHR (via AJAX), POST and POST_XHR. Usin PUT and DELETE are optional.


In turn the Controller invokes the appropriate Class and Method to handle the requirement. The Class and Method called could be a standard Cliqon facility or a Module or Plugin that you have written for yourselves. As long as you clone certain conventions as to how Cliqon Routing works, almost anything is possible.

Configuration

You will be familiar with the software design paradigm called “convention over configuration”. Our configuration files follow that convention but as we cannot call these files or database records anything but “configuration” files, we will use a different term for the heirachy and say “cascading”. You will be used to the term Cascade with reference to Style Sheets. All the Configuration values in Cliqon Cascade in a similar manner.


As an example, it takes three sets of configuration values to create a grid displaying language strings – the first set we call a service, thus a grid is a service, the second is a table that corresponds to a table in the database and finally a model or collection which configures a type of record, in this case a string.


Each of these configuration containers with TOML formatted values can exist in three places (the third is automatic). The container could exist as a file or it could exist as a database record. Once in existence and required it will automatically create a cached version as a file, which will be used until one or other of the containers is changed, upon which event, the cached version will be refreshed.


The idea has been developed within Cliqon for many years and versions but has come to maturity with Version 4 and is now used throughout the system.

Generating HTML or JSON via API

The concept and process of generating content and data as a JSON stream instead of returning HTML to a browser was completed with version 4. At this moment in time Cliqon 4 contains the facilities support both mechanisms for publishing content – rendering a template containing HTML or returning a JSON stream (local browser or remote device [JSONP]). As and when we get to a Version 5 of Cliqon all mechanisms to render HTML will be removed.


We consider that the mixed approach is the correct approach as not every developer has had time to make the conversion. At this time we support five mechanisms – publish a page of HTML, generated from a page template; render a component of HTML generated from a component template; add a JSON stream of data to either of these which is consumed in the correct place (before end of body) by the page template; render a stream of JSON that can be consumed as a page template by the client and finally render a stream of JSON data that can be rendered as a component.

Authorisation and security – User sessions and JWT

Following on from the above section, we needed to augment our facilities for statement management and security. We have always supported database driven sessions and Cookies. Thus UserNames, IDs’ and Access Level Controls have always been available for the purposes of managing User, Operator and Administrative access, at a fine level – that is using Read, Write and Delete controls, across menuitem, service, table, collection and field.


This level of security is enhanced by the provision of support for JSON Web Tokens (JWT) for all JSON local and remote communications. The raw facilities to support OAUTH are provided but the final development of this must be part of an end-user application.

Multiple languages

When we first developed the forerunner to the packaged Cliqon, which is now nearly fifteen years ago, the fact that we built into our framework, support for multiple languages was completely new and almost unique. Over the years we have tested our ideas on countless numbers of websites. For a long time, different language versions of a thing, such as a label string or document, would be held in different records. For some time now, we have kept alternate language versions within one record as JSON.


Thus one would expect to find a series of document fields where the system expects there to be a subarray structure within the JSON with language code and language string pairs. The following snippet is a good example: {“d_text”:{“en”:”Text”, “es”:”Texto”}}. Whilst there is no limit to the number of languages that could be installed and maintained, a practical limit of five is proposed. Once the language is in place it is easy to manage. Adding and deleting languages is automated but takes a while to achieve.

Templates – Razr or Javascript

As explained previously, Cliqon supports the use of template engine to render HTML. As Cliqon will gradually be moving away from all types of server side templating it makes no sense to provide any form of incredibly smart template engine such as Smarty or Twig. In any event, we have found the Razr template engine (which was originally developed by the Pagekit project team ) to be entirely adequate for Cliqon. It takes its idea from Razor templates within Microsoft.


Details and documentation for the Razr template language are provided in the manual.


Some years ago, we did our forward looking research and chose the Vue Javascript reactive framework for the administration module in Cliqon, as it worked well with both Bootstrap and jQuery which continue as essential aspects of the Cliqon project. Using Vue with PHP is like looking at two sides of grid or ladder. We can choose to connect the two components at almost any rung on the ladder – low or high. We can render a template with PHP and let Vue animate it with a data stream. Equally we can render just a JSON stream and let Vue create the template and then animate it. Both situations exist in Cliqon administration at this time.


As we have said previously, ibn the longer term we believe that the Server will only generate JSON and the client code will be responsible for all rendering.

Frameworks

We chose Vue for the backend and we use Vue for our own frontend and application projects. As developers, there is no reason why you should choose to do the same. The way the system is designed allows the Views and Mobile subdirectories containing “views” to use the Framework components that are appropriate for you, as the  developer. If you want to use Ember, React or Angular this is perfectly feasible.

Process for building websites

The basic production version of Cliqon visualises that a website will be created in a particular way and order.  However we do believe, from experience, that this is the way that experienced web developers and agencies build websites for clients.


The process starts by installing a production version of Cliqon. Then you can create or select and download a free or paid HTML website template. Full stack developers will not have a problem with the traditional and artificial differences between back-end developers and front-end designers, the latter may!


If the developer or agency has their own in house creative artists, the result you will be looking for is an HTML template, complete with any necessary javascript, images, fonts etc. If the developer has the responsibility for sourcing or producing the template, then the package sought is a straightforward package of HTML. Finally, we offer one suggestion and one aide for the design process. Any of the recent crop of website designers, such as Pingendo, do an excellent job in allowing the developer to produce the required HTML. The editor within Pingendo would allow the introduction of the Cliqon template variables, components and content. Cliqon 4 now offers, as a built in option, GrapesJS javascript layout constructor which also creates the necessary HTML site layout.


As a general rule, the HTML of the template will be copied into the Views subdirectory and the process of animating the template can begin.

Methods

Over the past 10 years that Cliqon has existed, we have developed a wide variety of core methods that you can use in the template. Although it is only an arbitrary definition, we think of a method call as something that returns a simple string of content, usually in the current language, which contains no formatting or element of presentation. One can imagine that a core method is used to access the database for a collection value and maybe format that value as might be necessary for a date or currency.


The list of static methods that can be used in that way is provided in the documention. It should be obvious that if we do not provide a core method, you can create one yourself as a Developer.

Widget

Over the same timescale of development, we have also developed a number of widgets or components that  render a collection of variables and may contain formatting. As a general rule the components will be specific to a modern CSS framework such as Bootstrap or Material Design. Again the list of components is documented and includes complex methods such as menus, lists, tables and trees. We believe that this is an area where Contributors and Partners may make the biggest impact. We ourselves will be developing themes, templates and components as plugins that we will make available by our Cliqon website. Some of these plugins will require administrative facilities and wizards.



Created with the Personal Edition of HelpNDoc: Write EPub books for the iPad