This section provides some technical details on a few of the key server side components within Locomote.sh.
Locomote.sh is a file-based CMS, and filesets are an important mechanism which allow different files within the CMS to be allocated to different categories, based on their file path. Fileset categories are then used to describe how a file and its contents are processed and replicated to clients, or to define user access to the contents of the fileset.
Locomote.sh provides an object-relational mapping layer as a way to represent data, other than file based content such as HTML, within the system. At its most basic, the ORM is used to map Jekyll front matter (found in source markdown files and containing meta-data about content files in the system) to meta-data tables on the client, where it can be used to perform queries on published content.
It is also possible to describe more complicated, multi-table data schemas using the ORM layer which source their data from e.g. JSON files added to the content repository, the contents of which are then replicated as relational data to mobile clients.
Locomote.sh provides a powerful access control mechanism (ACM) which provides flexible, fine-grained controls for accessing content and data published through the CMS.
By default, Locomote uses HTTP basic authentication to authenticate client requests.
The Locomote.sh build system is used to process content added to a content repository to make it ready for publishing. The build system is an extendable, multi-step process. Locomote.sh provides a number of standard process steps (described below), but it is easy to add more if needed.
The build process is a server side process that is automatically triggered each time content updates are pushed to a content repository.
In the standard setup, content builds are written to a separate repository branch, different to the branch that content updates are committed to. This separate branch is called the public branch, and is the branch that all ppubished repository content is taken from.
The Jekyll build step performs a Jekyll website build on content added to the repository. This reads markdown and other files in the repository, applies a Jekyll HTML theme to them, and generates styled HTML, CSS and other files which are then published to web or mobile.
The image build step is used to generate full multi-display image catalogs from a small number of source images. Source images can be placed into a directory structure, from where resized images targetting different display resolutions are generated and copied to alternative directory structures suitable for publishing to iOS or Android.
The docx build step is used to generate markdown and HTML files from Word documents which are added to the repository. This is useful for displaying the contents of Word files in a format more suitable for web and mobile. The step is capable of converting basic text formatting, images and tables to HTML.