Zotonic — A quick overview

In an earlier installment I wrote about the reasons why we started building the content management system Zotonic using the programming language Erlang. In this installment I will give a quick overview of the data model and the basic building blocks of Zotonic.

Modules, the basic building block

A Zotonic web site is made of different functional parts:

• Controllers, in fact Webmachine resources.
• Templates, all what you see. Templates can include other templates.
• Screen components, scomps, those are templates with their own little controller.
• Actions, everything that you can do with buttons, forms, jQuery effects etc.
• Validators, used to check submitted input elements.
• Css, Javascript, static images. Those are all put in lib directories.
• Dispatch rules. They map a request url to the correct controller.
• And a bunch of supporting Erlang code to make it all work.

A module contains one or more of the above items. All templates, actions, validations, css, javascript, dispatch rules and scomps are contained in modules. Modules have a priority and can overrule components of modules with lower priority.

Modules are directories with at least one Erlang module implementing a gen_server that manages the module. Subdirectories in the module contain all the templates, Webmachine resources, dispatch rules, actions etc.

Modules communicate with each other using notifications. Modules can be activated or deactivated using the admin interface (which is implemented using multiple modules).

Data Model

The data model is inspired by semantic web triple stores. But then adapted to make it work with a relational database and usual CMS interfaces and methods.

All (ok, most) data in Zotonic is a resource. Resources are connected with edges, creating a directed graph of information. Every edge has also a predicate. The predicate defines the meaning of the edge. For example author, as in the author of an article.

For example, a news article is a resource. The image of the news article is another resource, connected to the article with an edge, and so is the author of the article, the place the article is happening etc.

You could say that Zotonic has only two tables. A resource table and an edge table.

Resources are typed using a hierarchical category system. Some predefined resource categories are: text, news, image, video, sound, person, group, predicate, category and other.

A Data Resource

A resource has some fixed fields and can have any additional fields. The fixed fields are:

• Id, an unique integer.
• Title.
• Slug. Used to make understandable uris
• Introduction, a short abstract used in lists.
• Body, the textual body of a resource. A body contains HTML.
• Unique name, used by the system to find resources by name instead of id.
• Featured flag, to show things at important places on your site.
• Published flag.
• Publication period. From when till when a resource is published.
• Uri. The originating uri of the resource when it is imported from another site.
• Authoritative flag. Defines if the resource is imported or created locally.
• Category, defines what the resource represents. For example a person, article, event, image or video.
• Group. Editors work together in groups, all content belonging to a group can be edited by editors in that group.
• Visibility level. Defines if the resource is viewable by the group, community or the world.

All textual fields (except name and uri) can be multilingual. Any resource can have multiple extra data fields. Think of a date range, name or address.

In the next article I will show a bit of a template.