A content class is a definition of an arbitrary data structure. It does not store any actual data. A content class is made up of attributes. The characteristics of an attribute are determined by the datatype that is chosen for that specific attribute. By combining different datatypes, it is possible to represent complex data structures. The following illustration shows the anatomy of a content class called "Article", which defines a data structure for storing news articles. It consists of attributes dedicated for storing the title, an introduction text and the actual body of an article.

Example of a content class.

An eZ publish distribution comes with a set of general purpose classes that are designed for typical web scenarios. For example, the default image class defines a structure for storing image files. It consists of attributes for storing the name of the image, the actual image file, the caption and an alternative image text. The built-in classes can be modified in order to become more suitable for a specific case. In addition, it is possible to create completely new and custom classes. Content classes can be created, modified and removed easily using the administration interface. When a content class is removed, all instances of that class (containing actual data) will also be removed from the system. The following screenshot shows the class edit interface in action.

The class edit interface.

Class structure

A content class consists of the following elements:

• Name
• Identifier
• Object name pattern
• Container flag
• Default sorting of children
• Default object availability flag
• Attributes

Name

The name is for storing a user friendly name which describes the data structure that the class defines. A class name can consist of letters, digits, spaces and special characters. The maximum length is 255 characters. For example, if a class defines a data structure for storing information about graduate students, the name of the class would most likely be "Graduate student". This name will appear in various class lists throughout the administration interface, but it will not be used internally by the system. If a blank name is provided, eZ publish will automatically generate a unique name when the class definition is stored.

Identifier

The identifier is for internal use. In particular, class identifiers are used in configuration files, templates and in PHP code. A class identifier can only consist of lowercase letters, digits and underscores. The maximum length is 50 characters. For example, if a class defines a data structure for storing information about graduate students, the identifier of the class would probably be "graduate_student". If a blank identifier is provided, eZ publish will automatically generate a unique identifier when the class definition is stored.

Object name pattern

The object name pattern controls how the name of an actual object (an instance of a class) will be generated. A pattern usually consists of attribute identifiers (described later) that tell eZ publish about which attributes it should use when generating the name of an object. Each attribute identifier has to be encapsulated by angle brackets. Text outside the angle brackets will be included directly. If a blank pattern is provided, eZ publish will automatically use the identifier of the first attribute.

Container flag

The container flag controls whether an instance of the class should be allowed to have sub items (often called child nodes, children) or not. This setting only affects the administration interface, it was added in order to provide a more convenient environment for administrators and content authors. In other words, it doesn't control any actual low level logic, it simply controls the way the graphical user interface behaves.

Default sorting of children

From 3.9, it is possible to set the "default sorting of children" while editing the classes. When new objects are created and their corresponding nodes appear in the tree, they will use the sorting settings that were specified at the class level. In other words, if you set the "default sorting of children" to priority/ascending for the "Folder" class, the sub items of newly created folders will be sorted by their priorities, starting with the lowest priority.

Note that sorting parameters can always be changed for each individual node by using the sorting controls located in the "Sub items" window. Modifying the default sorting parameters at the class level will not affect the nodes that encapsulate existing objects of the class (only the nodes of newly created objects will be affected). Refer to "sort method" and "sort order" for more information about sorting parameters.

Default object availability flag

This flag is related to the multi-language features that were added in eZ publish 3.8. It simply dictates the default value of the "object availability" flag for new instances (objects) of the class. This flag can be further controlled (on the object level) by a checkbox labelled "Use the main language if there is no prioritized translation" in the "Languages" window of the administration interface. In other words, the object availability can be modified individually for each object. When the flag is set, an object that does not exist in one of the site/prioritized languages will be shown using it's initial/main language. If the flag isn't set, the object will not be shown as long as it does not exist in one of the prioritized languages.

Attributes

As pointed out earlier, it is the structure and type of the attributes that make up the actual data structure that the class defines. A content class must at least have one attribute. On the other hand, a class can contain virtually an unlimited number of attributes. Class attributes can be added, removed and rearranged at any time using the administration interface. If an attribute is added to a class, it will be added to all current and upcoming instances of that class. If an attribute is removed, it will also be removed from all instances.

Although it is possible to remove and add attributes using the administration interface, in some cases these operations may corrupt the database. This usually happens when there are too many instances that need to be updated. If the required processing time exceeds the maximum execution time for PHP scripts, the sequence will be interrupted and thus the database will most likely be left in an inconsistent state. At the time of writing, this problem can only be solved by increasing the maximum execution time, which is defined in "php.ini" as "max_execution_time". The default value is 30 seconds, it should be increased to a couple of minutes. A more reliable solution (a PHP script that takes care of adding/removing attributes and run it from within a shell) will probably be added in the future.