Each object in a Content Engine system belongs to a class. The class to which an object belongs determines its initial properties. All objects in a class are identical in form and behavior, but they may contain different values for their properties. Every Content Engine object has a property that describes the class to which it belongs, called the Class Description.
After you create an object store, you can extend its existing class definitions by creating custom classes that reflect your business needs. Use classes to organize content in your object stores.
Class Properties
The system automatically supplies certain property information, for example,
the Creation Date property. You can edit some system properties, while
others are read-only. Every class has system properties. However, you
can assign each class its individual set of properties called custom properties
that reflect the content organization needs for your business. For instance,
a subclass of document class named Contracts would have custom properties
for all parties involved in the contract.
Inheritance
When you create an object store, the system automatically creates class
definitions for all classes listed in the Enterprise Manager tree under
Document Classes and Other Classes. To create custom classes, you create
subclasses of those original class definitions. You can add custom properties
to these classes to reflect your business needs.
The document class object is the superclass of all other document classes you will create. All of the document classes you create will inherit system properties from the default superclass. A subclass always inherits all of the properties of its superclass. You can add custom (user-defined) properties to the default superclass, such as document class, but you cannot remove a custom property from a subclass if the property was inherited from its superclass. These inheritance rules may be important when you design your object stores and determine your superclass and subclass hierarchy. For example, at an insurance company, you may create a class named Policyholders. Subclasses of Policyholders could include a class named Claims. Additionally, changes to the superclass are inherited by its subclasses and are applied to any new versions or check-ins based on those subclasses.
There is no limit to the number of levels of subclasses a class can have. However, object store system administrators should consider putting restrictions on the number of sublevels to avoid an overly complex content management design.