UI Developers Guide

The Cloud CMS user interface is an HTML / JavaScript application that comes pre-configured with a base application that is feature-complete and out-of-the-box. It includes a ready-to-run content management and collaboration tool set for managing documents, web sites, mobile content and more.

It also makes some default assumptions about page layout, placement of buttons, availability of functionality and role-based provisioning that may or may not match your desired editorial workflow. Chances are that it gets things mostly right. But it's also very likely that as you use Cloud CMS, you may find places where you wish to extend or adjust the configuration of screens, layouts, controls and other things.

Cloud CMS lets you extend the user interface to provide new pages, buttons, modal popups, fields, form controls, wizards, and other UI elements. It does all of this through JavaScript using AMD (Asynchronous Module Definitions). You simply create your custom JavaScript in GitHub (or any other supported source control system) and deploy it to the user interface. No server side changes required and no downtime.

Similarly, Cloud CMS lets you configure the user interface entirely via JSON. Using our client-side JSON configuration service, your custom extensions can register and override new JSON blocks to reset the order of menus, show or hide pages based on roles, turn on and off buttons based on user rights and authorities and much more. Once again, no server side changes required.

In this fashion, it is easy to get started with Cloud CMS and extend as you go. Nothing is proprietary - everything is built using JSON and JavaScript. The application is pulled together in the browser and made ready to go via AMD loaders.

Configuration and Modules

At the core of the Cloud CMS user interface is a browser-side configuration service that quickly executes a series of contextual rules to determine what things to render on the screen. These rules take into account things like:

who the current user is and what roles they have
the items that are currently being worked on
permissions or access rights that the current user may or may not have against the current item being worked on
project and tenant settings
preferences configured by the user

Each rule consists of a evaluator and conditions and an outcome to be applied. If the rule evaluates to true, the outcome is applied. The outcome may consist of new configuration data (such as new buttons to be added to the screen). It may also consist of overrides (renaming things, repositioning things) or the removal of things.

These configuration rules therefore play the role of describing things like:

new pages to be added on the left-hand side
new buttons that appear in various menus
new form fields and control types
new dashlets and dashboard configurations
new plugins / add-ons and extensions

Once the configuration has determined which elements to include, it sets about pulling in those elements and dispatching to them for execution and rendering purposes. If you have any new elements, then custom code may be required to implement those elements.

Cloud CMS allows developers to build new UI Modules consisting of nothing more than JavaScript, HTML and CSS. These are packaged and delivered as AMD-compatible modules. These modules are loaded into the browser and utilize inversion-of-control patterns to register themselves as UI component providers.

As such, when the Cloud CMS user interface is rendering, it will look to the configuration to determine that a new component needs to be loaded. It will then load the component and dispatch the request to it. A component may be a full page, a portion of a page, a single form control field or many other pieces and parts of the application.

Configuration Service

Fundamentally, any new capabilities that you seek to add to the Cloud CMS user interface will need to begin with an introduction of new configuration that either overrides core configuration or extends it to provide new elements.

To learn more about the configuration service, please check out Configuration.

There are two ways to introduce new configuration rules / blocks. These are:

Create a UI Config (View) within the user interface
Develop and deploy a Custom UI module

The Cloud CMS user interface also a few places where very light adjustments can be made (such as changing the label of a menu option or toggling a menu option to display or not to display). To learn more about this approach for light changes to menu options, please see our documentation on Menu Configurations.

For a more extensive description of how to either build Custom UI Modules or Create UI Views, please read on.

Using a UI View

You can write new Configuration blocks (rules) directly within the Cloud CMS user interface. This configuration can be written at both the Platform and Project level.

A Platform UI Config document will be applied to users who are viewing the Platform within the user interface.
A Project UI Config document will be applied to users who are viewing the Project within the user interface.

When you create a UI Config document, you give it a name. These documents then appear in a drop-down in the upper-right corner of the screen. This allows you to effectively store different kinds of page configurations. Your users may opt to flip between different UI Config settings to get different tools. Or you may directly provision them.

To learn more about writing configuration using UI Config Views, please check out UI Views.

Using a UI Module

Each UI Module that you develop may include configuration that should be merged into the Configuration Service when the module is deployed. This allows you to package all of the configuration needed for the successful use of your custom modules together in one place. Folks just deploy your module and, wallah, everything comes together.

Modules

For further reading on UI Modules, please check out Modules.

Configuration

For further reading on UI Configuration, please check out Configuration.

Contexts

For further reading on UI Contexts, please check out Contexts.

Evaluators

For further reading on UI Evaluators, please check out Evaluators.

Actions

For further reading on UI Actions, please check out Actions.