Structuring Reusable and Scalable Content

Background

Headless CMS provides users with a content-focused approach, offering greater flexibility compared to traditional CMS and enabling unlimited customization possibilities. There are no strict rules on how users should structure their content templates or organize their content tree, freeing up the "head" or frontend part of the application to access the contents.

However, when it comes to website development, it is still a good idea to provide a structure to the content, drawing on years of experience working with traditional CMS. At Nimvio, we have incorporated this knowledge into our Nimvio Themes. In this guide, we will show you how content is structured for our Nimvio Royal Blue on White themes. To follow along and experiment with the content structure provided, we recommend starting a Nimvio project using the mentioned themes.

Content Classification

The content in the system can be classified into 4 groups/categories based on their function, which are Configuration, Templates, Layout, and Contents. The following tree structure displays these classifications, with the Layout group being expanded:

.
└── Content Root/
├── Configuration/
├── Templates/
├── Layout/
│ ├── Layouts/
│ └── Widgets/
└── Contents/

The following terminology applies to all items under each classification:

A Configuration Item is a sub-content of /Configuration
A Template Item is a sub-content of /Templates
A Layout Item is a sub-content of /Layout/Layouts
A Widget Item is a sub-content of /Layout/Widgets
A Content Item is a sub-content of /Contents

Configuration

The Configuration category holds all the website configurations used by the content, such as custom styles and fonts that can be modified as needed.

The collection of fonts is conveniently stored under /Configuration/Styles/Fonts for easy reference by the Fonts field of Styles Item. The concept behind this is that the same fonts from the Fonts Collection can be reused by each Styles Item.

Templates

The Templates category is designed to store default values for specific content templates. As an example, suppose a Content Item is utilizing a Content Template named Page. In this scenario, the Widgets field may require Widget Items that are frequently used, such as a header and a footer.

To avoid having to populate the Widgets field with common Widgets Item (e.g., header, footer, etc.) each time a new Content Item is created, we can store the common Widgets Item in a Template Item and reference it on the Templates field.

Layout

The Layout category is used for managing all the global configurations related to page Layouts and Widgets. In the case of the Royal Blue on White theme, it includes 1 Layouts Item (Default), and several Widgets Items, as shown in the picture below.

The Contents category is meant for storing all the Content Items related to the website pages. To create a structured content tree, it is recommended to follow the website page structure. Here's an example:

It is noticeable that the Content Item called Common does not correspond to any website page. This is because it is the only one that does not utilize the Content Template named Page. Common is used in the Royal Blue on White Theme as a grouping for common content, such as header, footer, and social links, which will be used as a widget data source for Widget Items.

What's Next?

Congratulations! You have just finished the guide on Structuring Reusable and Scalable Content. Keep exploring others below:

Creating Nimvio Theme

Developer