Introduction

In modern dynamic world – structure of the data has to be flexible to keep up with the changes. There could be a lot of different data sources, the structures of data can change and the relation between them as well.

That is why, designing Hubert, we decided to include the flexible, configurable content management system that will enable our customers to store and link various kinds of data.

In this document, we will try to introduce some core concepts of our CMS that will help you to understand the other documents on this page.

Fields

Most atomic component of any database is of course a field of some type supported by the database. This is also the case in Hubert CMS – data is contained in the fields and we support the following types of them:

• String – text of any size
• RichText – text with the elements of formatting
• Integer – integer value
• Boolean – logical value
• Double – floating point value (double precision)
• Enumeration – enumeration defined in the system to provide easy mapping between the integer and textual, multilanguage value. For example – list of countries.
• Date
• Time
• DateTime – date and time combined
• Typology – special type of field containing the classification information

Each of these types has also the array variant. So you can have a field that contains the array of strings or dates for example.

String and RichText fields can be defined as multilingual. So they can have a number of values in different languages.

Contents

Group of fields is called content in the Hubert CMS. So instead of speaking of the records (like in the traditional database), we use the content term here.

Schema

Schema is the definition of the content of particular type. Kind of blueprint of content type. It defines the collection of fields, relations to other types of content, ways in which the content should be filtered, sorted, displayed and edited.

So, we can have a schema describing the structure of the TV program event and structure of TV program title. And we can define relation between them. Later on we can also add another schema describing the person for instance. And add this relation to the title. We can also add the small contents describing texts and their copyrights. And add it to the mix. This structure can grow and be linked dynamically with your data.

Links and extensions

Inside the schema definition we decide how the contents of different types are related to each other. Let’s say that we have the following schemas available:

• tv-event – describing the emission data of TV program
• tv–content – describing the ‘title’ data (description of the film for instance)
• text – general purpose definition of the text – text itself plus some information regarding copyright and type of the text
• person – describing the person (name. surname, dates of birth and death, sex etc.)
• award – describing the award achieved by person or film

At first we could define a simple link between the tv-event and tv-content:

This link is defined as N:1 which means that for each tv-event there can be only one tv-content and each tv-content can be linked to multiple tv-events. The blue arrow on the diagram depicts a link.

Let’s say that you also have a collections of texts for the tv-event and tv-content. By modifying the linking definition you can transform this structure to:

Now every tv-event can have multiple Text’s (1:N). Also every tv-content can have multiple texts. This structure can be developed further by modifying definitions in the FRED database.

Using every schema in this example, we can construct the following structure:

As we can see, using the schemas as the building blocks we can build very complex, tree-like structures of the data describing the context stored in the Hubert CMS.

Attachments

Every content in Hubert CMS can have a collection attachments. Attachment is an object from our Phoboss Digital Asset Management System (DAM). Usually it is a photo, video or other kind of file indexed in DAM.

Because attachments are connected to the contents of any schema, by attaching them to the different contents in the example structure, we place them in proper context. In this example it would allow us to differentiate between event photos, content photos, photos of the person and event photos connected with the award (e.g actor winning the Oscar Award).

Mappers

Because structure of contents can be very complex and deeply nested, we need a way to extract data from this structure that is needed in particular context. To map fields from different levels of  this deep content tree into vector of fields.

Objects performing this operation are called mappers in Hubert CMS. They convert the structure of contents into collection of typed fields.

One can compare them to views in traditional databases and they are quite similar to views but their definition allows for performing a lot of additional operations and conversions during the mapping process.

Visualisations

Because the meaning of the fields is not known to the system, you have to provide some additional information to the schema that will enable system to show the data in the user friendly form. This visual definition is called visualisation. Multiple visualisations can be provided for the schema and they can be easily customised or created using visual editor provided with the system.

You can use different visualisations per product or user to fine-tune the presentation of the data.

Filters

For each schema, multiple filters can be defined to limit the number of contents in the view. Filters in Hubert CMS are defined as the small Python code snippets that define the filtering logic. In this logic, you can use fields from the whole structure of contents. Because filtering is supposed to be very fast process, we use the pre-calculation of the filter values for the contents. That makes the filtering process very predictable as far as the performance is concerned – regardless of the filter complexity.

Editors

You can also define multiple editors to provide the editing experience for the content. Visual form editor is provided in the administration part of the system.