Content Management Guide
CHAPTER 1
This chapter provides an overview of the Content Management (CM) subsystem and includes the following topics:
The CM subsystem provides a repository for documents, enabling you to create and version documents, manage document security, search the repository, and so on. The CM subsystem provides Web CM capabilities such as style and layout management and document publishing and expiration.
The CM API and CMS Administration console provide interfaces to the CM subsystem that assist you in managing Web content. Other front-end applications can use the CM subsystem as a general document management system. For example, you could use a WebDAV application and the CM subsystem to manage CAD files or legal documents.
What is meant by content? Content is defined as information that is viewed or downloaded by users of your exteNd Director application. The content managed by the CM subsystem is retrieved dynamically for online viewing or downloading when end users access your exteNd Director application.
The CM subsystem can store any type of content that can be digitized. It might store:
Text documents, with XML or HTML tagging or in any word processing format
Image files, such as GIF, JPG, QuickTime, and any other format
You can also store documents that support your content, such as:
It is up to you to store content in formats that are appropriate to your online application. A document doesn't have to be a complete item that would be displayed as is. A document can be a piece of data that you want to combine with other documents before displaying it, or some code resource that allows you to get data. For example, a document's content could be an URL, a set of URLs, a SQL statement, a paragraph, or an image.
The center of the CM subsystem is the document. Each document is described by a set of metadata that is a definition or description of data—in other words, data about data. In the CM subsystem, a document consists of all information required to maintain content (including the document's metadata, content, and versions) and all specifications for categorization, display characteristics, linked documents, access control, and so on.
A checkout/checkin system protects documents while you are changing them, and versioning allows you to maintain a history of content changes.
Publishing a document lets you choose a particular version of the document's content to make public. Once a version is published, you can define a fixed lifetime after which the version expires and can be archived and deleted.
For more information, see Managing Documents.
It is important to distinguish the type of content managed by the CM subsystem from the pages managed by the Portal subsystem. Pages constitute the structure of the application, defining the graphical user interface (GUI) that helps users navigate the site. Pages contain portlets—the building blocks of an exteNd Director portal application. It is within portlets that application developers write code to search for and retrieve content managed by the CM subsystem in response to rules and real-time user interactions. Typically, pages change infrequently—while content is more dynamic.
The CM subsystem enables you to manage content structure, display style, versioning, categorization, and security to facilitate the retrieval—and preserve the integrity—of information presented to end users of your application. The Portal subsystem manages the actual application, including the interface and architecture in which this content is presented.
For more information about pages and the Portal subsystem, see the section on portal concepts in the Portal Guide.
The CM subsystem infrastructure establishes the criteria for organizing, displaying, managing, and securing your content. It is designed to support the basic unit of content—the document.
There are two levels of infrastructure: physical and logical. You must set up the physical infrastructure before you can create documents. Optionally, you can also define a logical infrastructure anytime.
The physical infrastructure organizes the storage of documents in physical memory. This infrastructure consists of these components:
|
Component |
Description |
|---|---|
|
|
Root folder |
|
|
Folder |
|
|
Document |
There is a hierarchical relationship between folders and documents:
The top-level container is the root folder, which can contain one or more folders. A root folder is essentially just a specialized type of folder, one with no parent. In turn, folders can contain one or more documents or other folders. Each document resides in one (and only one) folder.
The logical infrastructure organizes documents into logical groupings that can be used to provide a user's view of content. There are several elements:
Document types, fields, and display styles define the structure and layout of documents, as described in Defining content structure and layout. Taxonomies and categories classify documents for search and retrieval, as described in Classifying content.
Before you create documents, the structure of the content must be defined. Before you publish documents, the look and feel of the content must be defined to determine how the information will appear to users of the Web site. Typically, a content administrator oversees these tasks by developing the fields, document types, display styles, folders, and categories described under Logical infrastructure above.
Content developers associate document types and display styles with the documents they create by following this pattern:
Create an instance of the document type and then create an XSL style sheet based on the content of that document.
Upload this XSL style sheet into a display style defined for the document type.
All documents you create based on the document type will contain the content structure and layout defined in the document type's display style.
A content administrator can create any number of document types, which consist of fields of information that dictate the structure of documents.
The CM subsystem provides default document types that can be accessed and modified by content administrators. In the CM API, the default document type is called Default; in the CMS Administration Console, it is called _PmcSystemDefaultType. These document types can be used to enforce a corporate standard for content or to create content in the absence of any custom document types.
The CM subsystem comes with a default display style that is applied to all document types unless you override it with custom display styles.
Content administrators can define custom display styles that use one or more XSL style sheets developed in external editors and then uploaded to the CMS Administration Console. Each XSL style sheet specifies how to render content for a particular user agent, such as Microsoft Internet Explorer and Netscape Navigator.
When you have specified your display styles appropriately, the CM subsystem automatically matches the desired style to the user agent that is active in real time.
You can create content without classifying it; but if your exteNd Director application allows users to select categories of information, a content administrator may want to create categories for grouping documents in a logical fashion. That way portlets can more easily access the documents specified by users as they interact with the Web site.
For example, suppose an exteNd Director application developer creates a portlet that lists URLs that link to specific documents. If documents are classified by category, the portlet can link to all documents of a particular category by looking for a parameter called category passed on the URL.
There is a hierarchical relationship between categories and documents:
The top-level container is the root category, which can contain one or more categories. In turn, a category can contain one or more documents or other categories. A single document can be associated with any number of categories—or with no categories at all.
The CM subsystem maintains a history of all document changes. The version history for a document might look like this:
When you check out a document, it becomes locked; no one else can check it out until you check it in or cancel the checkout. (Exception: the CM subsystem allows administrators to remove locks on documents if that becomes necessary.)
When you check in a document whose content has changed, a new version of that content is created. If you change the metadata but not the content, no new version is created when you check in the document. The metadata is updated but not versioned.
When a document has been approved, its content can be published as the officially released version of the document. When an application requests a document, the published version is the one provided.
The published version is not necessarily the latest one, however. Modifications can continue as content developers check out the most recent version of the document. Publishing a document creates a stable version of the document for the public.
The CM subsystem includes built-in support for these functions:
You can integrate CM with any other exteNd Director subsystem, including:
|
Related subsystem |
Description |
For more information see |
|
Search |
Supports conceptual and keyword searching of document content and metadata. |
Chapter on conceptual searching in the Content Search Guide |
|
Security |
Used to secure access to CM subsystem elements. |
|
|
Workflow |
Used to access CM documents in workflow applications. |
Chapter on the Content Life Cycle application in the Workflow Guide |
Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...
