Schemas

Schemas describe your content. It's very similar to a database schema but not identical. In your schemas you can define how the editors will interact with your content and how your content is going to be saved.

There are 6 types of schemas:

• Standard
• Hierarchical
• Singleton
• Subschema
• Combo
• Resource

Standard Schema

The standard schema is what you will use for most situations. It's like a database table. You can define your fields and form your documents' schema. You can then query them as you would do in any database.

Each schema will always have a title and a id field by default. You cannot remove them but you can edit the title. The '.

All the custom fields that you are going to include in your schema will store their data in the content object inside the document. For example, the title will be accessed as content.title.

Hierarchical

The hierarchial schema is the way to maintain tree-like data. Each document has a parent and you can query them either in a standard way, or request the children of a parent to get a nested tree object.

This is ideal for categories, wikis or any other tree like structure. The current documentation is an hierarchical schema for example, where each page has a parent one.

Each document in this structure has a tree object with the following information:

{
    "tree": {
        "path": "id1.id2",
        "parent": "id2",
        "order": "P"
    }
}

Path is the materialized path of the document. It contains the ids of all the parent documents, dot delimited.

Parent is the id of the immediate parent.

Order is the order it has on it's current level. Meaning you can sort by this field in an ascending direction to get the documents in order.

Singleton

Well, this is simple to explain. There are cases where you need only one document inside a schema. Let's say for example, that you need a document for the homepage's texts. You can create a singleton schema, which will store exactly one document. You can access that document directly, skipping the list in the UI. Other than that it is identical to the standard schema.

Subschema

A subschema is the way to define the fields of subdocuments. Subdocuments are a great way to reuse schemas inside documents. It's better to explain it with an example.

Let's say that you want have a card object that will have the following fields: name, image, caption, summary. Let's also say that this card object will be reused in different schemas in your website. You have 2 options. The one is to create those 4 fields each time for each schema, or create a subschema and relate it to the other schemas.

Reusing subschemas is a powerful design tool. Also, subschemas can be repeatable, making them a great way to create repeatable nested objects in your schemas.

The data of subdocuments are not save in the content object. They live in the subdocs object instead for reasons of clarity organization.

Combo

The Combo schema is a way to make your own field combination and use them as new type of field. It is another great way to reuse schema but it has some crucial differences in compariton to subschemas.

Differences

• Subschemas can have translated fields. Combos can be translated as a whole, not on a field basis.
• Subschemas live in the subdocs object, combos exist in the content object.
• Subschemas can contain combo fields. Combo fields cannot contain subschemas.
• They have different UI. Combo fields can be great for quick editing

Resource

Each channel can only have a resource schema. This schema except the title and the slug field, it has the data field which is also required. The main purpose of this schema is to populate the select field types.

Let's say that you want to have a select field with all the countries of the world. You can create a Resource document containing a JSON with all these countries. The json format must have the following schema, otherwise it won't work.

[
    {
        "label": "Afghanistan",
        "value": "AF"
    },
    {
        "label": "Åland Islands",
        "value": "AX"
    }
    .
    .
]