Contenta terminology

Frequently used and typical Contenta terms are described.

TermDefinition
Compound objectsThe Compound object is a Contenta object type with addressable components called slices.
It serves as a container and/or a data object.
  • As a container object, it may be used to create a hierarchy and house other objects, or it may be used to create a hierarchy and house other objects while also containing data itself.
  • As a data object, it is a leaf node and can only house data.
SlicesThere are two main categories of slices, Child slices and Content slices.
  • Content slices contain data. The slice contains data that is a piece of the document stored in an object, in a hierarchy of objects that together, is the whole document.
  • Child slices contain a map to the location of data that comprise the document.

Slices are especially necessary when using compound objects since compound objects may contain data in a hierarchy that does not comprise a continuous flow of information.

For example, the top-level compound object may contain an introduction and a closing statement—the data in the document that falls between those statements may be in other compound objects under the top-level container. In this case, the slice is a necessary map to keep track of what data should be located where in your document.

Dynamic Import (DI)Dynamic Import (DI) is the Contenta tool for importing data and/or a hierarchy into a Contenta database.

Refer to the Dynamic Import User section of the Contenta documentation for more information about this tool.

AppDataApplication Data—storage for database-specific (not machine-specific) information or data.

For example, appdata contains the location of the DTD and how to build a header when a structured data object is opened in Contenta.

AppData has a tree structure similar to the windows registry, with key and values. Keys can contain subkeys or named values.

AppData can be user-specific or global.

Tools APIThe Tools API provides a procedural interface.

Use if you want to quickly develop simple tools to support specific document management activities.

Data is not cached.

Client APIThe Client API provides a higher-level interface.

Supports tree-hierarchy of objects that users navigate to manipulate. By default, it caches information for faster performance when traversing and displaying the Contenta hierarchy.

Use to develop customized, broad-based document management applications similar to Contenta interface activities.

Properties and AttributesAn object’s property sheet contains the object’s metadata such as the object’s name, access level, document type, etc.

The properties tab contains fields which are the same for all instances of the same object. The attributes tab contains fields that can be unique to a specific instance of an object.

Attribute fields can be created and populated dynamically such as through Dynamic Import.

Property fields can be also populated with Dynamic Import or through the use of customized tools.

PortalThe Contenta Server listener.

PcmPortal is one of the main elements of the Contenta Server package. PcmPortal is a middle tier process that implements

Contenta server-side logic. It serves as the middleman between multiple Contenta clients and the database server.

pcmcmdThis is the command line interface to the PcmPortal.
Adapter

Customizable import and export applications.

Adapters:
  • export and import Contenta data
  • extend the API by plugging into it
  • simplify export/import customization
  • adapt tools to different publishing and editing requirements
  • encourage component level reuse
Adapters are:
  • components of the tools API
  • invoked by API's command (or the client API’s node) interface methods GetDocPerl and PutDocPerl
  • linked to API via COM (CORBA on Unix)
  • language independent of tools that use them