The DecentCMS and Orchard content type systems compared

The content type system in Orchard is one of the reasons for its great flexibility. The ability to build your own content types from building blocks that are just the right size is essential to building a great CMS. Orchard has content types that are made of content parts, that can have properties and fields. Parts are aspects of a type, such as title, comments, or body, that there can be only one of per type. Fields are named, and there can be any number of each type of field per content type. Confused yet? There’s a reason for all this, of course, but in DecentCMS, I’ve opted for a simplified version.

DecentCMS also has content parts, but they can be named, so that the distinction between part and field is not necessary anymore. Some parts such as title or body can still have special semantics, based on naming conventions, which makes those closer equivalents of Orchard parts, while other parts are arbitrarily named, which would make them similar to an Orchard field. They are all parts however.

Parts themselves are complex objects in Orchard, that can have fields, and properties. Fields are typically stored in parts of the “infoset” (an XML document stored in the database on the content item record), while properties can be stored on the infoset, or on an underlying part record.

In DecentCMS, the whole content item is one big JavaScript object, that gets persisted on disk as a single JSON or YAML document. Storage is a lot simpler, and it’s easy to get a global view of an item without having to look at several related tables in the database. This very blog post, for example, could look like this:

{
  title: "The DecentCMS and Orchard content type systems compared",
  body: "The content type system in Orchard...",
  tags: ["DecentCMS", "Node.js", "Orchard"],
  author: "bleroy",
  created: "2015-02-24T04:57:56+00:00",
  published: "2015-02-24T04:57:56+00:00",
  comments: [
    {
      author: "Some guy",
      published: "2015-02-24T06:00:32+00:00",
      body: "Cool stuff."
    }
  ]
}

Note that part values can be simple types such as strings when that makes sense, or they can be complex objects when that’s necessary. The same part can even take different forms based on the circumstances. For example, whereas this post’s body part is a simple string, here is what the body part of the decentcms.org home page looks like:

{
  body: {
    src: "../../../README.md"
  }
}

As you can see, the body part of that page may still be the same text part as the one on the blog post type, but instead of being stored as a simple string, it is an object that points to a Markdown file. This is useful in this case in order to re-use the project’s README.md file that is at the root of the project. There is flexibility here that would be much harder to reproduce with a statically-typed language and a relational database.

The type definition also benefits from document storage. Type definitions are documents that are stored as part of the content module’s settings for the site. Here is what the type definition could look like for a blog post:

{
  "blog-post": {
    name: "Blog post",
    description: "Blog post",
    parts: {
      title: {type: "title"},
      body: {type: "text", flavor: "markdown"},
      tags: {type: "taxonomy", taxonomyId: "taxonomy:tags", multiple: true},
      author: {type: "user"},
      comments: {type: "comments"}
    }
  }
}

The Orchard and DecentCMS type systems are very close in philosophy. DecentCMS however, being built on a dynamic language and document storage, can benefit from some rather drastic simplifications while keeping its spirit and its flexibility pretty much intact if not even better.