A content class is made up of one or more attributes where each attribute is represented by a datatype. The characteristics of an attribute are determined by the datatype that is chosen for that specific attribute. An attribute is made up of the following elements:

• Name
• Identifier
• Generic controls
• Datatype specific controls

Name

The name is for storing a user friendly name for the attribute. For example, if the attribute is supposed to store birthdates, the name of the attribute would most likely be "Date of birth". This string will appear in various parts of the administration interface, but it will not be used internally by the system. The name of an attribute can consist of letters, digits, spaces and special characters. The maximum length is 255 characters. If a blank name is provided, eZ Publish will automatically generate a unique name for the attribute when the class definition is stored.

Identifier

The identifier of an attribute is for internal use. In particular, attribute identifiers are used in configuration files, templates and in PHP code. An attribute identifier can only consist of lowercase letters, digits and underscores. The maximum length is 50 characters. For example, if the attribute is supposed to store birthdates, the identifier of the attribute would probably be "date_of_birth". If a blank identifier is provided, eZ Publish will automatically generate a unique identifier when the class definition is stored.

Generic controls

Each attribute has a set of generic controls. These controls are the same for each attribute, regardless (but not independent) of the datatype that represents the attribute. The generic controls are a set of switches that can be turned on or off:

• Required
• Searchable
• Information collector
• Translatable

Required

The required switch controls the behavior of the storage procedure for content objects (instances of a content class). It can be used regardless of the datatype that represents the attribute. When the required flag of an attribute is set, the system will keep rejecting the inputted data until all required information is provided. If the required flag is unset, eZ Publish will not care whether any actual data was provided or not. When an attribute is added, the required switch is off. Please note that inputted data will be validated according to the chosen datatype's validation rules regardless of the state of the attribute's required switch. Input validation is supported by most (but not all) of the built in datatypes. The following example demonstrates how these features actually work.

Let's say that we have created a content class that defines a data structure for storing information about prisoners. The class would typically consist of various attributes for storing different kinds of data: name, identification number, date of birth, cell, block, etc. Having at least the name and the birthdate attributes required will eliminate the possibility of storing convicts without names and/or birthdates. If the birthdate attribute is represented by the built-in "date" datatype, the system will only accept the input if the birthdate is provided using a correct date format.

Searchable

The searchable switch can be used to control whether the actual data stored using the attribute should be indexed by the search engine or if it should be left unindexed. Search indexing is supported by the majority of the built-in datatypes. Please refer to the "Datatypes" section of the reference chapter to see which datatypes that support search indexing.

Information collector

The information collector switch can be used to control the attribute's behavior in view mode. The default view mode behavior results in the display of the information that was provided in edit mode. For example, when viewing a news article, the contents of the article are displayed but can not be edited. However, if an attribute is marked as a collector, it will allow information to be input in view mode. At first, this feature might seem a bit odd. However, it is actually quite handy. For example, it can be used to quickly create simple feedback forms. The contents of a form created using this technique will be e-mailed to the site administrator (or to a specified address) once the form is submitted. Information collection is only supported by a small set of the built in datatypes. The following example demonstrates how this feature could be used to create a basic feedback form.

Let's say that we have created a content class called "Feedback form" using the following attributes: name, subject and message. The subject and the message attributes would be marked as information collectors. When an instance of this class is viewed, the subject and the message attributes will be displayed as input fields along with a "Send" button.

Translatable

The translatable switch controls whether actual data stored using the attribute should exist in only one language (the default language) or if it should be possible to translate it using the additional languages. The translation mechanism is completely independent of the datatype layer. In other words, this switch can be used regardless of the datatype that was chosen to represent the attribute.

When an attribute is added, the translation switch is "on". Turning it off is typically useful when the attribute is supposed to store non-translatable input. For example, translating dates, numerical values, prices, email addresses, etc. doesn't make much sense.

Datatype specific controls

An attribute can have a set of additional controls that are specific for the datatype that was chosen to represent that attribute. Some datatypes allow fine grained customization, some not. For example, the built-in "Text line" datatype provides two settings: default value and maximum length.