Overview | Package | Class | Tree | Deprecated | Index | Help
| Copyright © 2006 BEA Systems, Inc. All Rights Reserved
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES

## Package com.bea.content

This package and sub-packages work together to provide BEA Portal Content Management.

See
Description

Class Summary
BinaryHelper | A helper class for dealing with binary data.
BinaryValue | This class represents binary content.
ContentContext | Holds contextual information related to the current CM call in a loosely-structured manner.
ContentEJBHomeCache | This class caches the initial context and the EJB Home so lookups for EJBs are faster.
ContentEntity | A ContentEntity is an object that is identified in the content management system by a unique id.
ContextKey | Context keys are used to store and retrieve context values in the class ContentContext.
Credentials | The credentials for an authenticated subject.
ID | The ID of a content element.
Node | A Node represents an element in a hieararchy.
ObjectClass | ObjectClass is the type for a Node.
PathHelper | Utility class to manipulate unix path like Strings such as /a/b/c/d.
Property | Property is a name value pair, with the name being unique relative to the Node and the value is an Array of Value objects.
PropertyChoice | PropertyChoice defines a set of choices for a PropertyDefinition, and thus any Property instances based on it.
PropertyDefinition | PropertyDefinition defines the shape of a Property.
RepositoryId | A `RepositoryId` uniquely represents a BEA Content Repository.
Value | The value for a Property.

Exception Summary
AuthenticationException | This Exception is thrown when a user fails authentication.
AuthorizationException | Thrown if a user is not authorized for an action.
DefaultWorkflowException | Thrown if an operation on a PropertyChoice that does not exist occurs.
InvalidNodeNameException | This is the main checked exception for any error thrown from the SPI.
NodeExistsException | Thrown if an operation on a Node that already exists occurs, such as attempting to rename a Node to the Name of a Node that already exists.
NoSuchNodeException | Thrown if an operation on a Node that does not exist occurs.
NoSuchObjectClassException | Thrown if an operation on a ObjectClass that does not exist occurs.
NoSuchPropertyChoiceException | Thrown if an operation on a PropertyChoice that does not exist occurs.
NoSuchPropertyDefinitionException | Thrown if an operation on a PropertyDefinition that does not exist occurs.
NoSuchPropertyException | Thrown if an operation on a Property that does not exist occurs.
NoSuchWorkflowException | Thrown if an operation on a PropertyChoice that does not exist occurs.
ObjectClassExistsException | Thrown if trying to create an ObjectClass that already exists.
ObjectClassInUseException | Exception used to denote that a particular operation can not be performed on an ObjectClass becuase it is currently in use.
PropertyChoiceExistsException | Thrown if trying to add a PropertyChoice to an ObjectClass with the same name as one that already exists.
PropertyDefinitionExistsException | Thrown if trying to add a PropertyDefinition to an ObjectClass with the same name as one that already exists.
PropertyExistsException | Thrown if trying to add a Property to a Node that already has a Property with the same name.
RepositoryException | This is the main checked exception for any error thrown from the SPI.
RepositoryRuntimeException | This is the main runtime exception for system errors.
TransitionNotFoundException | Exception to indicate if a workflow transition has not found.
UnsupportedRepositoryOperationException | An exception thrown from a repository implementation to signify that the operation is not supported by the implementation.
ValueOutOfBoundsException | Thrown if trying to get nested property via it's indexedName, using an index that is greater than the size of the Value array.
WorkflowExistsException | Thrown if an operation on a PropertyChoice that does not exist occurs.

## Package com.bea.content Description

This package and sub-packages work together to provide BEA Portal Content Management. Most interaction with the content management system will be done through the classes and interfaces of the com.bea.content.federated package. The starting point is the com.bea.content.ContentManagerFactory. It provides methods for obtaining various manager classes used to manipulate and manage content repositories.

- ContentManagerFactory.getNodeManager() - Used to fetch an INodeManager. This interface provides methods for working with content nodes. For example, to create a new node called "newNode in the BEA Repository using the type "someType" you would execute the following code:

      INodeManager nodeManager = ContentManagerFactory.getNodeManager();
      node = nodeManager.addNode(context, PathHelper.SEPARATOR + "BEA Repository" + PathHelper.SEPARATOR + "newNode", "someType", properties);

  To retrieve this same node you would execute:

      Node newNode = nodeManager.getNode(context, "/BEA Repository/newNode");

- ContentManagerFactory.getTypeManager() - returns an ITypeManager used for interacting with content types. A content type is represented by the com.bea.content.ObjectClass.
- ContentManagerFactory.getSearchManager() - returns an ISearchManager used for performing security aware searches on content nodes.
- ContentManagerFactory.getVirtualRepositoryManager() - returns an IVirtualRepositoryManager used for managing repositories.
- ContentManagerFactory.getWorkflowManager() - returns an IWorkflowManager used for managing workflows as well as associating them with nodes and types.
- ContentManagerFactory.getVersionManager() - returns an IVersionManager used for managing nodes in a library services enabled repository.

The following is a brief description of each package:

- com.bea.content - provides the value classes that are shared between the virtual repository and an implementation of the BEA Content SPI.
- com.bea.content.federated - provides classes that federate the interaction with all configured repositories. These are the classes that are used to add, update delete and retrieve nodes, types and workflows.
- com.bea.content.indexer - provides classes to invoke indexing of content.
- com.bea.content.paging - provides for pagination and iteration of content retrievals and searches.
- com.bea.content.manager - provides a virtual view of configured repositories. These configured Repositories are in effect the "Published" repositories. The classes from this package are deprecated. Instead use the classes in com.bea.content.federated package.
- com.bea.content.virtual - provides management of the virtual content repository. This allows for content and metadata to be versioned and approved for publishing. Some classes from this package are deprecated. The entry point to the functionality of the virtual content repository should proceed through the com.bea.content.federated package.
- com.bea.content.spi - provides the service provider interfaces that need to be implemented in order for a repository to plug into the virtual repository.
- com.bea.content.expression - provides the interfaces and classes that are used for the virtual search and as the search parameters to an SPI implementation.
- com.bea.content.loader - provides the ability to load content from a file system into the virtual repository.

BEA Portal Content Management centers around the Virtual Content Repository. The Virtual Content Repository (VCR) performs two functions:

1. It acts as a content federator to SPI implementations by forwarding content actions to the appropriate Repository.
2. It optionally adds Library Services to configured BEA Repositories. Library Services adds versioning and custom workflow to content in a BEA Repository. The basic flow for a Node in a Library Services Enabled Repository is as follows:

- When a node is created with a type (ObjectClass) and properties, the node and system properties, such as creation date and created by are added to the repository. However, the type defined properties are not yet visible to facilities like content selectors and content search. For the type defined properties to be associated with the type the workflow status must be "Published".
- A virtual node, along with a version is created in the Virtual Repository. The version contains the type defined properties.
- Each time the virtual node is checked out, a working version is created and it becomes assigned to and locked by the user performing the check out.
- When the virtual node is checked in with the same status the system unlocks it, but it stays assigned to the user. If a different user then checks it out, the system locks it and assigns it to the new user that checked it out.
- The workflow for a node can be a custom user-defined workflow or a default workflow can be used. The default workflow defines 5 different status; DRAFT, READY, REJECTED, PUBLISHED and RETIRED. Each time the virtual node is checked in with a different workflow status, a workflow action will occur. For example, when checking in from "Draft" to "Ready For Approval", the virtual node will get assigned to all users in the "Publisher" role. When checking in from "Ready For Approval" to "Published", the type defined properties and the type association will be copied to node in the repository. When checking in from "Published" to "Retired" the type defined properties and type association will be removed from the node in the repository. When checking out a Node that is "Retired", the workflow status is changed from "Retired" to "Published", thus the node's system properties and type association become available for search queries. Furthermore, with custom workflows, user-written code can be fired when transitions from one status to another occur.
- When working with the Virtual Content Repository API it is important to note that all actions in the manager package immediately occur on the configured Repository with one exception. On a copy for a Library Services Enabled Repository, the node is immediately copied in the configured repository, however each node in the copied hierarchy also becomes checked out to the user performing the copy in order for the type defined properties to go through the workflow. All actions in the virtual package occur in the Virtual Content Repository's datastore. However, when checkIn is called with either a Published or Retired status, type defined properties and the ObjectClass association may be copied to, or removed from the BEA Repository.

The components that make up a Virtual Content Repository are listed below.

- Repository - is an instance of a configured SPI implementation. There may be more than on instance of a particular SPI implementation. Interaction with a repository is done through the com.bea.content.federated package.
- Library Services Enabled Repository - a repository where all type defined properties in the repository will be versioned and will also require approval to be published (written) to the Repository. Currently only the BEA SPI implemenation may be Library Services Enabled.
- Workflow - the approval process for Node properties to be published to a repository.
- Virtual Content Repository - Provides a federated view of configured repository instances and also manages Library Services Enabled Repositories.
- Virtual Repository API - The com.bea.content.federated package is the entry point to interacting with the virtual content repository.

Overview | Package | Class | Tree | Deprecated | Index | Help
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES

Copyright © 2006 BEA Systems, Inc. All Rights Reserved