About 'Pages'

a short overview

Introduction

At the beginning was the Composum Core Console later renamed to Composum Nodes with the Browser as the main console feature to walk through the repository. This is currently part of the Apache Sling starter.

But the idea was a little bit bigger...

At the end a full featured Content Management System was the goal. A first prototype was presented at adaptTo() 2016. And now the troubles of the level began. After a lot of iterations the first final release of the CMS called Composum Pages is now available. You can see it in action here. This site is made with Composum Pages on the Composum Cloud platform.

An instance of the Composum platform consist of three or four modules:

  • the Nodes module is the basic layer with a general repository and user interface API and with the known repository tools
  • the Platform module provides all necessary services to set up a system which can be used for authoring and to deliver the published content all done by only one instance; this module provides also the API for the content release management
  • the Asset module was implemented as a prototype to manage images and responsive renditions - this module is currently deferred; there is a refactoring planned to also use the release management features of the Platform in the Assets module
  • the  Pages module is the Content Management System on top of the Platform services; it's a framework to implement Sling content components und a content management application with an extendable user interface

One instance for All

It should be easy to install the CMS for development and it should be an option to have the same installation in development and in production probably in a clustered installation. Therefore the Platform module enables the setup of one sling instance for authoring and as the publishing instance.

An 'Access Filter' determines the access mode (author / preview / publish) by analysing the host information and restricts the access according to that access mode. Based on the access mode the release or version of the content to deliver is calculated and an appropriate resource resolver is defined for the request rendering.

The Pages part in this chain is to evaluate the requested site and its configuration and map the access mode to the right release of the sites releases list.

'Pages'...

Features

Pages is the content management module of Composum which is providing an user interface to manipulate your content in an intuitive way. The content in the Composum Pages CMS is organised in

  • Sites:
    the managing entry point to one site on the platform which contains all pages and assets and declares the releases, languages and all settings for the pages of that site
  • Pages:
    a page represents a page in the Web; the page hierarchy determines the navigation of a site; pages are versioned and the versions of the pages are organised in the site releases
  • Containers and Elements:
    the content pieces of a page are arranged in containers placed on a page with more or less complex content elements within

The pages content is edited in a modularised and customizable user interface:

1
2
3
4
5

Everything is a Component

The 'Pages' CMS is declaring a framework to implement content components. Such a component itself is providing a set of editing components which are embedded in the CMS editing user interface. The framework contains a default implementation for each implementation aspect of a content component.

A content component can implement a Sling component for:

  • an edit dialog
  • an edit toolbar
  • an edit tile (type and instance)
  • a set of tree actions
  • custom context actions

Besides the content components all the other UI elements of Composum Pages are also Sling components. These components of the edit frame are also customizable and extendable. 

Especially the set of dialog widgets and the set of navigation and context tools placed on sides of the edit frame are extendable.

Registry services are collecting all available tools and widgets automatically. They must be readable in the resolvers search paths only.

The known overlay mechanism in the resolvers search path is supported for all tools, widgets and components.