Content Management Guide
|
|
Content Management Guide |
The Content Management subsystem provides a repository for documents, enabling you to create and version documents, manage document security, search the repository, and so on. The Content Management subsystem provides Web content management capabilities such as style and layout management and document publishing and expiration.
The Content Management subsystem API and Portal Management Console (PMC) provide interfaces to the Content Management subsystem that assist you in managing Web content. Other front-end applications can use the Content Management subsystem as a general document management system. For example, you could use a WebDAV application and the Content Management subsystem to manage CAD files or legal documents.
This section provides an overview of the Content Management subsystem and includes the following topics:
What is meant by content? The content managed by the Content Management subsystem is retrieved dynamically for online viewing or downloading when end users access your Director application.
The Content Management 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.
Content and documents The center of the Content Management 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 Content Management subsystem, a document consists of all of the 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.
Content and pages It is important to distinguish the type of content managed by the Content Management subsystem from the pages managed by the Portal subsystem. Pages constitute the structure of the application, defining the graphical user interface that helps users navigate the site. Pages contain components—the building blocks of a Director portal application. It is inside components that application developers write code to search for and retrieve content managed by the Content Management subsystem in response to rules and real-time user interactions. Typically, pages change infrequently, while content is more dynamic.
The Content Management 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 Portal Concepts in the Portal Guide.
The Content Management 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:
|
Component |
Description |
|---|---|
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.
Document types A content administrator can create any number of document types, which consist of fields of information that dictate the structure of documents.
The Content Management subsystem provides default document types that can be accessed and modified by content administrators. In the Content Management API, the default document type is called Default; in the Portal Management Console (PMC), 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.
Display styles The Content Management 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 PMC. Each XSL style sheet specifies how to render content for a particular user agent, such as Microsoft Internet Explorer and Netscape Navigator.
Once you have specified your display styles appropriately, the Content Management 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 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 components can more easily access the documents specified by users as they interact with the Web site.
For example, suppose a Director application developer creates a component that lists URLs that link to specific documents. If documents are classified by category, the component 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, categories 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 Content Management subsystem maintains a history of all document changes. The version history for the document might look like this:
|
Version ID |
MIME type |
Content data |
Size |
Date |
Modifier |
Comment |
|---|---|---|---|---|---|---|
Checking out documents 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. (The Content Management subsystem does allow 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.
Publishing a document 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. 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.
|
|
Content Management Guide |
Copyright © 2002, SilverStream Software, Inc. All rights reserved.
