The role of a content management system is to organize and store content regardless of type and complexity. The main goal of such a system is to provide a well structured, automated yet flexible solution allowing information to be freely distributed and instantly updated across various communication channels (such as the world wide web, intranets and miscellaneous front and back-end systems). This section describes how eZ Publish actually handles content.

A typical example

Let's consider a scenario at a university with a need of storing information about students. Most off-the-shelf content management systems will offer a selection of built in content types. There might for example exist a "Person" type, consisting of fields like "name", "birthdate", "phone number" and so on. However, the custom student data will probably not fit perfectly into this predefined model since it might consist of information that is specific for the university (for example student ID, department, etc.). Even though some systems allow the creation of custom structures, the solution is often a complicated and time consuming process that requires both programming and manipulation of the database. In addition, once the solution is in use, future alternation of the structure itself will most likely become a problem.

Content management in eZ Publish

Unlike other content management systems, eZ Publish does not make use of a predefined "one-size-fits-all" approach. Instead of desperately trying to fit data into predefined and rigid structures, the system allows the creation of custom structures by the way of a unique object oriented approach. For example, the site developer can build custom structures that perfectly satisfies the storage needs of the university. This is one of the key features that make eZ Publish a flexible and successful system. In addition to offering the freedom of custom structures, it also allows the modification of the content structures at run-time. In other words, if the custom student structure used in the example above needs to be modified, then eZ Publish will automatically alter it based on the administrator's commands.

Although the possibility to create and modify content structures is a wonderful feature, there isn't always need for using it. This is why an eZ Publish distribution comes with a selection of predefined content structures and thus allows the developer to choose between the following scenarios:

• Use the standard/built-in structures
• Use modified versions of the standard/built-in structures
• Use only custom structures
• Use a combination of standard, modified and custom structures

An object-oriented content structure

The eZ Publish content structure is based on ideas borrowed from the object oriented world of popular programming languages like Smalltalk, C++, JAVA, etc. Superficially, object-oriented means nothing more than looking at the world in terms of objects. In real life, people are surrounded by several objects: furniture, cars, pets, humans, etc. Each of these objects have traits that we use to identify them. This is also the way eZ Publish defines and manages content.

The system offers a selection of fundamental building blocks and mechanisms that together provide a flexible content management solution. An actual data structure is described using something called a content class. A content class is built up of attributes. An attribute can be thought of as a field, for example the "birthdate" field in a structure designed to store information about students. The description of the entire structure would be referred to as the "student class". The characteristics of an attribute inside the class are determined by the datatype that was chosen to represent that attribute.

It is important to understand that a content class is just a definition of an arbitrary structure. In other words, the class itself describes the structure but it does not store any actual data. Once a content class has been defined, it is possible to create instances of that class. An instance of a content class is called a content object. Actual content is stored inside objects of different types. A content object consists of one or more versions. The versioning layer makes it possible to have different versions of the same content. Each version consists of one or more translations. The translation layer makes it possible to represent the same version of the same content in multiple languages. A translation consists of attributes. The attributes are the final elements in the content structure chain, this is where actual data is stored.

The content objects are wrapped and organized by the way of nodes that are placed inside a tree-like structure. This tree is often referred to as the node tree. The following sections contain comprehensive explanations related to the elements that were introduced above.