Custom Objects
A custom object is a general-purpose object that is represented
by a CustomObject object that can be subclassed,
is independently securable, and can be persisted to the object store.
The CustomObject class provides a minimal set
of properties and exists primarily as a simple, customizable class
that you can subclass and to which you can add custom properties.
Unlike a Document object, a CustomObject object
does not carry content, is not versionable, and does not support lifecycle functionality. In
cases in which you need an object only to carry properties and do
not need it to carry content or be versionable, a CustomObject object is
preferable to a Document object without content because
it has fewer properties and uses fewer resources.
A custom object has the following characteristics:
- Its class can be subclassed.
- Its class can be customized by the addition of custom properties.
- The class to which it belongs can be changed to an existing
CustomObjectsubclass. - It is containable; it can be filed into a folder and can belong
to a static referential containment relationship (that is, it can
be referenced by a
ReferentialContainmentRelationshipobject). - It can have one or more annotations that are associated with it.
- It can be the target of a workflow subscription; that is, it can have a workflow that is attached to it that either can be manually started or started when an event occurs.
- It can subscribe to server-side events that fire when an action occurs.
- Its operations can be audited.
- It can participate in cooperative locking; that is, a flag can be set on the object that specifies whether it is locked. Cooperating applications can test for the lock and, if found, treat the object as if it has read-only access.
- It does not have a defined name property; the value of its Name property defaults to the value of its Id property.
- It does not carry content (except for annotations), is not versionable, and does not support lifecycle functionality.
CustomObject
instances or the ability to full-text index them, consider by using a
CmAbstractPersistable custom root class instead. Performance and scalability for
custom root class instances can be superior to that of CustomObject instances. See Custom Root
Classes.For code examples that demonstrate how to create and use custom objects, see Working with CustomObject Objects.
Name Property
To increase
its flexibility, the CustomObject class (unlike most classes)
does not provide a specific system property that is designated as
its name property. Therefore, unless you add a custom name property
to the CustomObject class (or one of its subclasses),
the value of a CustomObject object's Name property
defaults to the value of its Id property.
To create a custom
name property for the CustomObject class or one of
its subclasses, follow these steps:
- Add a custom string-valued property to the class definition that defines the particular custom object class.
- Set the IsNameProperty property of the custom property's property
definition (
PropertyDefinitionStringobject) totrue.
After you instantiate a new CustomObject object
and set the value of its custom name property, the CustomObject object's
Name property will be automatically populated with the value of the
custom name property instead of the Id property.