The Interface Builder’s Data Model

The Interface Builder’s Data Model

With Scrivito, all editable content is stored in content objects, sometimes also referred to as “CMS objects”. Such objects contain the data of pages or images, for example, and are the only entities that are stored and retrieved individually, together with the widgets they may include.

Let’s take a look at a simple page and try to identify its components, the widgets. We’ll ignore the layout elements (outside the boxed area on the screenshot below) since most of them are related to the application and include only small portions of content used for rendering navigations, for instance.

  • Like every page, this one, too, is represented by a single content object. Objects are stored in a database in which each of them occupies exactly one entry.

  • The headline, the text block, and the image are widgets. They’re not content objects but contained in an attribute of the object. However:

  • The image is contained in an image widget but is a content object of its own. If you were to delete the widget or the page containing it, the image itself would remain in the system because the widget just references the image object (see below for details).

What's in a content object?

All content objects are based on a model that defines their properties. In Scrivito’s terminology, a page model is called object class, and properties are attributes. The object class for simple pages like the one above could look like this:

The flexibility and usefulness of this object class for the editor is based on the body attribute, a widgetlist. All the widgets an editor places on such a page are added to this attribute. Next to widgetlist, various attribute types for maintaining different kinds of content exist.

In addition to such an object class, we merely require a component that renders its instances, i.e. the actual pages, which comes down to rendering their respective body attribute, like so:

Widgets have attributes, too

You’ve probably seen widgets in action already. As an editor you can choose them from the various kinds of widgets available in your project. As indicated above, placing one onto a page means adding it to a widgetlist attribute.

The kind of content widgets of a specific type should be able to contain can be defined by providing a model, analogously to content object classes:

As you can see, the widget model above includes two attributes, headline and level. Note that you can add widgetlist attributes to widget models, too. The ability to nest widgets makes it possible to let editors structure content in a more refined way using column or section widgets, for example.

Behind the scenes: storage

As indicated, Scrivito stores all content objects in a database, keeping track of their attributes. The example page above is represented as a data structure similar to the one you can see here. An attribute of the widgetlist type, here body, is an array whose elements represent the widgets it contains.

The attributes given to objects via their object class are custom attributes. However, every content object also has a built-in set of system attributes, e.g. id for identifying them, or _path for maintaining the tree-like hierarchy objects may be part of. The data Scrivito stores for a content object includes both kinds of attributes.

As pointed out above, images are handled as individual objects that are referenced wherever they are needed. Thus, the value of the image attribute of the ImageWidget is an ID referencing the image object in the system.

Binaries are special

Scrivito identifies binary content such as images, videos, PDF files, etc. through attributes of the binary type in content objects. Let’s take a look at the typical definition of an Image object model.

The attribute name used here is blob, Scrivito’s default name for accessing the binary, e.g. for rendering.

When uploading a binary file to an Image object, Scrivito transfers it to Amazon’s S3 file storage and places its URL in the blob attribute of the content object. All this is done transparently in the background; nobody needs to clear away image files after the widgets or content objects referencing them have been deleted.

A word on indexing for searching

Scrivito maintains search indexes for the published content as well as for each working copy. All the attributes of a content object, e.g. a page like the one above, including the attributes of the widgets it contains, are indexed and associated with that specific object. So, one content object not only corresponds to exactly one entry in the database but also to exactly one entry in the search index.

Summarized, ...

Content objects and all their textual content including their metadata are stored in a database. Binary data is persisted using file storage services and linked to objects in the database. Scrivito maintains search indexes for all the content in all working copies.