Unified API Developer Manual / Version 2010
Table Of Contents
Every
CapObject
and
CapType
is equipped with a stable string ID that can be persistently stored and converted back into an
object reference as needed. To this end,
CapObject
has got a method getId() for retrieving the ID. Methods for converting IDs into
object references are typically provided by the repository objects.
Every ContentObject
and every Member
on the Content Management Server also has an additional UUID,
a stable and universally unique identifier as defined in RFC 4122. UUIDs are not meant as replacement of simple
string IDs, but make sense in certain scenarios. For details on ContentObject UUIDs,
have a look at Section 5.2, “UUIDs”. For details on Member UUIDs,
have a look at Section 7.2, “UUIDs”.
It is recommended that you treat the string IDs as opaque strings, because the exact format of the strings might change in future releases of CoreMedia CMS. Still, CoreMedia provides detail information about the IDs for the purposes of debugging and for interfacing the Unified API with legacy clients which might insist on using numeric IDs.
The class com.coremedia.cap.common.IdHelper is provided for formatting and parsing all sorts of ID strings. Note that all methods in that class may be redefined arbitrarily in the next CoreMedia CMS release.
The following table summarizes the various ID formats for CapObjects.
| ID string | Interface | Description |
|---|---|---|
|
| Content |
document or folder |
|
| Version |
version of document parameters: numeric content ID/version number |
|
| Process |
process |
|
| Task |
task parameters: numeric process ID/numeric task ID |
|
| WorkflowView |
initial process view parameter: numeric process ID |
|
| WorkflowView |
ordinary process view parameter: numeric process ID |
|
| WorkflowView | task view parameters: numeric process ID/numeric task ID |
|
| User | user |
|
| Group | group |
Table 4.3. ID formats for CapObject
The CapTypes are also identified by an ID.
| ID string | Interface | Description |
|---|---|---|
|
| ContentType | content type |
|
| XmlGrammar | XML grammar |
|
| ProcessDefinition | process definition parameter: numeric process definition ID |
|
| TaskDefinition |
task definition parameters: numeric process definition ID/numeric task definition ID |
|
| WorkflowViewDefinition |
initial process view definition parameter: numeric process definition ID |
|
| WorkflowViewDefinition | ordinary process view definition parameter: numeric process definition ID |
|
| WorkflowViewDefinition | task view definition parameters: numeric process definition ID/numeric task definition ID |
Table 4.4. ID formats for CapType
There are some other objects that are also assigned an ID, but that do not implement
CapObject
or
CapType.
Such objects implement the method getId(), but they do not provide getters and
setters for properties.
| ID string | Interface | Description |
|---|---|---|
|
| Publication | a publication that has been enqueued |
|
| PublicationTarget | a publication target |
|
| CapSessionInfo | a session that has been opened on the Content Server |
|
| CapServiceInfo | a service of the Content Server for which logins are possible |
Table 4.5. ID formats for other objects
Unified API objects that define an ID are equal in the
sense of Object.equals(Object), if and only if their IDs are equal and if they
belong to the same Unified API connection.
It is recommended to use the IDs for external storage only. The identified objects of the Unified API are lightweight, so that it makes no sense to store IDs in main memory for a long time. IDs are more difficult to handle and often larger than their object counterparts. But for storage in a database or a file, IDs come in handy.
IDs are also used by some of the administrative command line tools and for generating debugging output.