The content repository is concerned with the handling of folders and documents. The
Unified API presents folders and documents jointly through
the interface
Content,
which is a sub interface of
CapObject.
In releases prior to CoreMedia CMS 2005, the term
resource was used to refer jointly to folders and
documents. But that term was meant to indicate a very much reduced signature that allowed only
for those methods that are common to folders and documents. The interface
Content,
however, provides all methods that are applicable to either documents or folders. Besides
Content,
there is the
Version
interface, which represents a historic version of a Content.
In the class diagram from Figure 5.1, “Class Diagram: Content and Versions”, you can see the above mentioned classes and their associations. The ContentType interface will be discussed later in Section 5.2, “Types”.
A document may have an arbitrary number of versions, which are linked in a
predecessor/successor chain. You can get the versions of a document by means of
getVersions().
Besides these regular versions, checked-out documents have got a working version that represents their current state. The working version differs significantly from other versions. Most notably, its properties may change over time as the checked-out content is changed. Normally, you should not need to access the working version, as the associated content itself provides a richer and conceptually cleaner interface. For migrating legacy code, however, it might be natural to use the working version, so that a uniform interface is available.
Folders do not have any versions and they do not define any properties. Instead, they provide access to their children, which may be either documents or folders. You can retrieve all children or a child with a specific name by using the appropriate methods defined in Content.
There are quite a few methods that allow you to inspect the state of a content. You can query whether a document is deleted, whether it is checked out, who created it, and the like. This information is available as regular properties of the CapObject. You have to call the individual getter methods for obtaining this information.
A content supports many updating operations. In particular, it inherits the methods for setting properties from CapObject. Before changing the properties, a document must be checked out. After changing the properties, it may be checked in or, more rarely, be reverted to the original state. Keep in mind that, as noted in Section 4.9, “Sessions”, property changes are buffered and sent to the server only when the CapConnection is flushed explicitly.
Additionally, there a several other methods that deal with moving, renaming, copying, and deleting content. Currently, these operations are executed immediately. They are not buffered.
A Content object may enter various states during its lifetime. The full state space is quite large with over 50 different states. However, there are a number of orthogonal views that can be more compactly presented and that define the possible transitions completely.
Only documents may be checked in and out as described in Figure 5.2, “Statechart: Checked In and Out”. Folders are always checked in.
The next figures apply to the publication process, which is handled by the PublicationService as described in Section 5.4, “Publication Service”. Please refer to that section for details about the mentioned methods.
The place approval states of a content are quite simple, but they are shown in Figure 5.3, “Statechart: Place Approvals” to indicate that a place disapproval can happen implicitly during a number of operations.
As shown in Figure 5.4, “Statechart: Deleting”, a content becomes deleted, when a
deletion is published or when the content is deleted explicitly. It can be moved out from the
Deleted state, reaching the Undeleted state,
which it keeps until being deleted again or published.
One last state chart refers to the state of Version objects.
A version of a document is created when the document is created or checked out. In Figure 5.5, “Statechart: Version” you can see the lifecycle of a version. Typically, the content is checked in, so that the version is promoted to a regular version and is no longer a working version. The version is then approved and published, so that it appears on the live system.
When the diagram references the destroy operation, this applies either to an explicit
destroy() call of the version or the content, to an action of the document
collector or version collector, or to a cleanup during publication when the publisher is
configured to destroy intermediate unpublished versions.
 |  |  |
 |