Content Type Definition

A content type defines a type of content that your content workers generally create, edit and publish. For example, an article or a press release might be considered to be a content type. The content type defines the schema, properties, behaviors and everything to do with a specific kind of content.

You then set about creating instances of that content type. These are sometimes referred to as content instances. Instances are instantiations of a type. All content instances adhere to the specifications defined within the content type.

If you are a developer, then you can think of a content type in a similar way to how you might think of a class. A content instance is an object instance you typically get by instantiating the class (i.e. new constructor and so forth).

If you are not a developer, you can think of a content type as a blueprint. It defines the plans for building something and how that thing works. For example, you might have a blueprint for a building. A content instance is then the actual building. It's constructed and a real thing (no longer an idea) but it still adheres to the design specified on the blueprint.

All content that you create in Cloud CMS has a Type Definition. The default Type Definition is n:node. This Type Definition is a bit special in that it doesn't enforce it's schema. You're allowed to create JSON documents of type n:node and they can have any arbitrary schema.

If you want to begin to enforce schema, you do so by creating your own Type Definition. A Type Definition, at it's core, is simply a JSON Schema document. Here is an example of a Type Definition for an article. It has a title, a body and a rating. It claims the QName custom:article.

{
    "title": "Article",
    "type": "object",
    "properties": {
        "title": {
            "type": "string",
            "title": "Title"
        },
        "body": {
            "type": "string",
            "title": "Body"
        },
        "rating": {
            "type": "number",
            "minimum": 0,
            "maximum": 10
        }
    },
    "_qname": "my:article",
    "_type": "d:type",
    "_parent": "n:node"
}

The _type field is used throughout Cloud CMS to specify the Type Definition of a node. In this case, since our JSON above is for a definition node, the type is d:type which indicates that we are defining a brand new type.

All Type Definitions by default are assumed to extend the parent type definition n:node. For more information on setting up inherited schemas, see Inheritance below.

Defining your Content Types

Everything in Cloud CMS is based on JSON schema. You simply make changes to the JSON for your definition and all content instances (future or existing) will adhere to your design.

There are 2 choices in Cloud CMS on how to create and manage the Content Types: edit the JSON definition or use the Content Model Builder that makes it a bit easier to work with JSON schema. Check out the documentation on Content Model Builder.

To define a content type you simply go into your project, and click on Content Model in the left nav menu item.

Click on Create a Definition and then enter the properties for your definition. Each definition needs to have a unique QName of the form namespace:localname. In this case, we can use something like custom:article though it can be anything you choose.

The Content Model Builder will open and you can proceed to edit either in the UI:

Or edit the JSON:

Once saved, you can make changes to your content type definitions at any time. All changes are compiled server-side without any interruption to your currently running application or data.

If you have existing data and the changes you make to your schema somehow "break" the existing data, an exception is raised and the commit fails. This means that your data, once live, is guaranteed to be in a good state. You may be blocked from making changes to content type definitions once data is out there in the wild.

What can be done if you do need to make changes? There are two good options - one is to introduce a new content type (such as custom:article2 and the other is to use a branch to make bulk modifications to both your content type definition and all content instances. Doing this on a branch means that the live data isn't affected. Once your branch changes are good, you merge them back or inform your application to use the new branch as a source for it's data.

Creating and Editing Content

Content Types are used everywhere within Cloud CMS. If you work with Documents, you're always creating content with a content type. The default content type is n:node. And so, most of the time, if you're just uploading things or creating schemaless JSON, you're creating content of type n:node. Who knew!

But you can get more fancy with this.

Rather than dig around in folders to find the right content (which is perfectly fine to do if you wish to do this), another option is to just work with content types, and forms independently of folders.

Select Content from the menu.

On the left side, you'll see a list of your content types. On the right side, you'll see a list of your content instances.

Pick the Article type on the left-side and then click Create Content. Use the wizard to create your new content instance.

That's all there is to it. The Content Instances page lets you work with content types and instances straight away. It lets you create content, edit content and delete content without having to dig around in folders and directory paths.

Content Model Builder

Cloud CMS includes a Content Model Builder that makes it a bit easier to work with JSON schema. While most developer types are quite comfortable modeling their content types in JSON, it's sometimes easier to have a visual tool that can handle most things for you. Check out the documentation on Content Model Builder.