The Hippo repository is based on the Content Repository for Java Technology (JCR). This repository works on the basis of nodes where each node can have a number of properties and sub-nodes.
Each folder in the Hippo CMS is represented by a node. Similarly, the content items are represented as sub-nodes hanging below the parent folder. This way the content is organized into a large tree structure of nodes and sub-nodes.
Hippo provides the “Console” as an interface to browse through this tree structure, typically available under http://localhost/cms/console/ if you have an instance of Hippo running on your local machine.
The left pane in this interface show the tree structure, the right pane lists the node types properties, and mixin types.
Each node in the repository is defined according to a type definition. This definition defines which properties and sub-nodes it can or must have. There are two categories of node types: primary and mixin.
Every node has a single primary node type assigned to it upon creation. Additionally, one or more mixins can be added to a node later in its lifecycle. The primary node type of a node usually defines node structure (i.e., allowed and required sub- nodes and properties).
In simple terms, a mixin can be considered as a set of predefined properties or sub-nodes.
For example the mixin hippotranslation:translated adds the properties hippotranslation:locale and hippotranslation:id to the node. So this mixin should only be applied if translated versions of the same content item are required.
Content items like pages are stored in the /content/documents node. Each Hippo document is represented in the repository by a small collection of nodes hanging below a node with a constant id, called a handle.
In Hippo terms this ID is called a UUID. The UUID of this handle will never change so all inbound links to this document should point to this handle. Different versions of the same content item are hanging below this handle.
Content types (node definitions)
The documents are created according to the node definitions, which can be found in /hippo:namespaces (on the same level as /content). These definitions describe what properties a node has and what kind of subnodes it can have. The following example is the node definition for a news item (project:nieuwsbericht):
- politie:titel (string) - politie:subtitle (string) - politie:introductie (string) - politie:datum (date) - politie:gebied(string) - politie:landelijk (boolean) + politie:afbeelding (hippogallerypicker:imagelink) + politie:alineas (politie:textblok) multiple + politie:locatie (politiemaps:location) multiple
Rows prefixed with a ‘-‘ indicate a property of this node, and rows with ‘+’ indicate a subnode of the given type.
The definitions for all these subnodes (eg politie:alineas) are also contained in the namespace file. In this way each document is a small tree of specifically defined nodes.
Images are contained in the /content/gallery node. You might see a lot of versions for each image there, since Hippo can save many sizes of the same image as separate files.
All binary content items that are not images, are classified in Hippo as ‘assets’. Assets are stored in folders under the /content/assets node. Unlike images, they are not stored in sets.
Below the handle node, an asset is stored as a node with a hippogallery:asset sub-node that contains the binary jcr:data property.
Sometimes files are also added to nodes as a binary property; this is being investigated.