Skip to content

Content Management Framework

Jump to bottom
Geert Bevin edited this page Mar 19, 2023 · 2 revisions

RIFE2 provides a Content Management Framework (CMF) that is geared towards the process of storing, loading, validating, formatting, transforming, versioning, retrieving and streaming of various content types. Currently, the emphasis has been placed on providing features that are needed when putting content data into a back-end repository and getting the data back out.

The actual management of the content once it is stored has not yet been implemented in an elaborate manner, but this will be done in a future version

Overview

All CMF content is stored in repositories that must have unique names. The installation of a content manager creates an initial default repository. If others are needed, they must be created explicitly.

All content is identified by a unique location.
The location is formatted like this: repository:path

If the repository: prefix is omitted, the content will be stored in the 'default' repository. The path should start with a slash, which makes it 'absolute'; this is completely analogous to unix file system paths.

Content is stored through an instance of ContentManager and RIFE2 includes implementations for the storage in PostgreSQL, MariaDB, MySQL, Oracle, Derby, HSQLDB and H2 databases.

Below are a few terms and their definitions in the context of the CMF:

  • ContentManager
    The main interface that handles all high-level content operations (create, get, delete, etc.). All code behind this interface is implementation dependent. RIFE2 currently provides an implementation that is backed by a database, but it's totally possible to provide alternative implementations on top of WebDAV or JSR-170 for instance.
  • ContentStore
    An interface to handle the actual storage of content data. There are multiple content stores available, each responsible for handling certain types of content data. Examples are text data, image data, and raw data.
  • ContentDataUser
    When content data is retrieved from a content store, a concrete implementation of this abstract class will be given a handle to the actual content data, valid for a limited period of time. This is important since some content data (such as streamed binary data) is volatile and never fully loaded in memory.
  • Attribute
    This provides additional information about how the content data is to be formatted. For example, for images this can be a width or a height, in order to ensure that images are scaled before being stored into the ContentStore.
  • Property
    This provides information about the formatted content data as it is actually stored in the ContentStore. Even with no attributes defined, content data can still have properties. For instance, an image still has a width that will be detected and stored for later usage.
  • MimeType
    All content is tagged with a mime type that indicates how it will be further processed. There is one special mime type, RAW, which causes the content to be stored as-is without any manipulation.
  • Formatter
    This uses a Loader to get a typed representation of the raw content data, then formats it according to any defined attributes, transforms it, obtains the formatted data's properties, and converts it back to raw content.
  • Loader
    This makes a best-effort attempt to load raw data into a generic typed object, and collects any associated error messages. A loader will typically delegate the actual loading to external libraries when they are available. Examples of those libraries are the JDK XML parser with XHTML DTDs, ImageIO, ImageJ, ...
  • Transformer
    This can transform the generic typed object of content data that has been created by the loader into another object of the same type. For example, to perform image manipulations or compositions.

Workflow

The database implementations have the following workflow:

Store content

  1. Select a suitable ContentStore based on the content's MimeType
  2. Look up the content Repository
  3. Store the content info (metadata) for the specified location (i.e. path)
  4. Store the content Attributes
  5. Store the content data into the ContentStore:
    1. Obtain a Formatter for the content data
    2. Use the Formatter to format the data:
      1. Load the raw content data into a newly-created Java object of an appropriate type (such as java.lang.String for text data and java.awt.Image for image data)
      2. Report any loading errors
      3. Format the content according to any attributes provided
      4. Transform the formatted content if a Transformer has been provided
      5. Obtain the Properties of the final content
      6. Convert the Java object back to raw content data
    3. Store the formatted content data into the ContentStore:
  6. Store the formatted content data's Properties

Use content data

  1. Retrieve the content info for the specified location (i.e. path)
  2. Select a suitable ContentStore based on the MimeType that is provided by the content info
  3. Make the content data available via from content store:
    1. Look up the content data
    2. Call a ContentDataUser instance with the raw content data that was retrieved, and make it available to the caller

Next learn more about Content Query Manager

Clone this wiki locally