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 CustomObject subclass.
- 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 ReferentialContainmentRelationship object).
- 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.
Tip: If you do not need the containable behavior of
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 (PropertyDefinitionString object) to true.
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.