Datatypes, attributes, a content class and objects.
A content object is an instance of a content class. While the class only defines the data structure, it is the content objects themselves that contain actual data. Once a content class is defined, several content objects / instances of that class can be created. For example, if a class for storing news articles is created, several article objects (each containing a different story) can then be instantiated. The following illustration summarizes and shows the relation between datatypes, attributes, a content class and content objects.
Datatypes, attributes, a content class and objects.
Please note that the illustration above is a simplified version of the reality. It doesn't show the exact structure of the objects since the versioning and the translation layers have been left out. The following text gives a more in-depth explanation of the object structure. The versioning and the translation layers will be explained in the upcoming sections.
Note: A non-technical understanding of the "Content Object": one piece of content like an article, a picture or a movie, managed by eZ Publish. Describing attributes like author, title, subtitle etc. are belonging to the content object. A single content object can have different translations and versions. One and the same object can be used and displayed in several channels and contexts – i.e. one picture, used in different publications is still regarded as one content object.
A content object consists of the following elements:
Every object has a unique identification number. The ID numbers are used by the system to organize and keep track of different objects. These ID numbers are not recycled. In other words, if an object is deleted, the ID number of that object will not be reused when a new object is created.
The name of an object is nothing more than a friendly name that appears in various lists throughout the administration interface. It helps the user to identify different objects by their names instead of having to deal with identification numbers. An object's name is generated automatically by the system when the object is published. It is the object name pattern definition of a class that dictates how objects of that class should be named. This mechanism makes it possible to automatically generate names based on the object's attributes. Since the object name is not used by the system, different objects can have the exact same name.
For example, when dealing with news articles, the title of the article would most likely be used to generate the object names. When an article object is published, its name will be a copy of the object's title attribute. The name of the object will be updated every time the object is published. In other words, if the title is changed, the object's name will automatically also be changed.
Also, please be aware that the name of objects is always searchable, even if the attribute(s) used to generate the object name is/are defined as "not searchable".
The type information indicates which class that was used to create the object.
The object's owner contains a reference to the user who initially created the object. At any time, an object can only be owned by one user. This reference is set by the system the first time the object is published. The ownership of an object can not be manipulated and will not change even if the owner the object is removed from the system.
The published field contains a time-stamp pinpointing the exact date and time when the object was published for the first time. This information is set by the system and it can not be modified. The published time-stamp will remain the same regardless of what happens to the object.
The modified field contains a time-stamp revealing the exact date and time when the object was modified. This information is set by the system and it can not be modified. The modified time-stamp will change every time the object is published.
The status indicates the current state of the object. There are three possibilities:
When initially created, the object's status is set to draft. This status will remain until the object is published and thus the status will be set to published. Once published, the object can not become a draft. When a published object is moved to the trash, the status will be set to archived. If a published object is removed from the trash (or removed without being put in the trash first), it will be permanently deleted.
The section ID of an object denotes which section that object belongs to. Each object can belong to one section. By assigning different sections to objects, it is possible to have different groups of objects. The section mechanism is explained under "Sections".
The actual contents of an object is stored inside different versions. A version can be thought of as a timestamped collection of data (the object's attributes) that belongs to a specific user. Every time the contents of an object is edited, a new version is created. It is always the new version that will be edited. The current / published version along with earlier versions will remain untouched. This makes it possible to revert unwanted or accidental changes. An object always has at least one version of its content. Each version is identified by a number which is automatically increased for every new version that is created. The structure and logic of the versioning mechanism is explained in the next section.
The current version is a number that pinpoints the currently published version of the object. As described above, the contents of an object may exist in several versions. However, only one of them can be the current version (also referred to as the published version). The current/published version is the version that will be displayed when the object is viewed.
Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2013 eZ Systems AS (except where otherwise noted). All rights reserved.