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.

Defining your Content Types

Things really get interesting within Cloud CMS once you start to define content types. You do this by creating type definitions to model out your types. Check out the documentation on definitions to learn all about definitions.

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.

To define a content type, you simply go into your project and click on Definitions under the More 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.

You'll now see it show up in the list. Click on it!

Select JSON from the drop down menu to edit the schema for the definition.

And then define your schema using JSON schema:

Save your changes using the Save button.

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, instances and forms independently of folders.

Select Content Instances 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.

Visual Schema Designer

Cloud CMS includes a visual schema designer 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.

To access the visual schema designer, simply pick Design in the drop down menu.

Default Paths

You can set up your content types so that any instances of content created is automatically placed in a target directory structure within your project. This directory structure is determined automatically for you at save time and can be specified using contextual and content-driven variables.

Select Paths from the drop down menu. You can then specify a default path and file name to use for any new or updated content instances of this type. Here is an example:

When content instances are created of this type, they will be stored in /articles/${document.locale} and will have the filename ${document.title}.txt. Thus, the storage paths of any created content is automatically handled for our content workers and is driven by data in the content itself. It can also be driven from contextual information (such as current project or user properties).

For example, if you created a JSON document like this:

    "title": "Hello World",
    "summary": "My first article",
    "body": "My first article is awesome",
    "locale": "en_US"

It would be saved as /articles/en_US/Hello World.txt.

For a quick in-context reference on the kinds of content variables that are available, click on the Content Variables link.

Here is a breakdown of the content variables you can plug in:

project.id The ID of the current project
project.{a.b.c} Any dot-delimited property of the current project
application.id The ID of the current application
application.{a.b.c} Any dot-delimited property of the current application
user.id The ID of the current user
user.name The name of the current user
user.email The email address of the current user
user.{a.b.c} Any dot-delimited property for the current user
document.id The ID of the document
document.filename The filename of the document
document.qname The QName of the document
document.type The type of the document
document.{a.b.c} Any dot-delimited property of the document

This lets your content workers focus on using forms to simply enter data. Once entered, things just end up getting put into the right place.