Defining Content Types

Content Repository : Developer Guide

The content repository requires you to define each type of content supported by your supplication. Content types are defined as ACS Object Types, and may be created in the same fashion as any other object type. This page provides some specific examples and details related to defining ACS object types in the context of the content repository.

Determine content attributes

A content item typically consists of two components:

1. Text or binary data stored as a single object
2. Structured attributes stored as distinct values

Note that a content type does not have to store its primary content in the BLOB column of the cr_revisions table. There is some additional overhead associated with retrieving small passages of text from the BLOB column compared to an attribute column. In most cases the difference is trivial (fewer than about 10 microseconds), but if many items must be queried at the same time the difference may become significant. If the primary content will always be small, it is perfectly acceptable to store the content in an attribute column instead.

Basic attributes for all content types are stored in the cr_revisions (note that they are stored in the revisions table so that attributes may be updated for each new revision of the actual data). Most types of content require more than the basic attributes. For example, when storing images you will usually want to store the pixel height and width so that images can be selected and sorted by size, as well as displayed efficiently.

Create an attribute table

Extended attributes associated with ACS object types may be stored as key-value pairs in a central table (generic storage), or in a custom table whose primary key references the associated ACS object ID (specific storage). To ensure efficient access to attributes, the content repository API requires you to use specific storage. Your table should have the form:

create table cr_content_type (
    content_type_id       integer
                          constraint cr_content_type_id_fk
                          references cr_revisions
                          constraint cr_content_type_pk
                          primary key,
    attributes...
);

Note that your extended attribute table must reference the cr_revisions table, notcr_items. As mentioned above, this allows you to maintain multiple revisions of the attribute data in tandem with revisions of the content object itself.

Use the Content Type API to create the content type

To define a content type, you should write an SQL script to create the content type and then add attributes to it:

declare
 attr_id        acs_attributes.attribute_id%TYPE;
begin

 -- create the content type
 content_type.create_type (
   content_type  => 'cr_press_release',
   pretty_name   => 'Press Release',
   pretty_plural => 'Press Releases',
   table_name    => 'cr_press_releases',
   id_column     => 'release_id'
 );

 -- create content type attributes
 attr_id := content_type.create_attribute (
   content_type   => 'cr_press_release',
   attribute_name => 'location',
   datatype       => 'text',
   pretty_name    => 'Location',
   pretty_plural  => 'Location',
   column_spec    => 'varchar2(1000)'
 );

 ...

The content_type methods use the core ACS Object Type API to create an object type for each content type, and to add attributes to the object type. In addition, content_type.create_type will create the extended attribute table with an appropriately defined primary key column (referencing its supertype) if the table does not already exist. Likewise, content_type.create_attribute will add a column to the table if the column does not already exist.

Most importantly, the content_type methods call content_type.refresh_view after each change to the content type definition. Each content type must have an associated attribute view named table_namex, where table_name is the name of the extended attribute table for a particular content type. The view joins the acs_objects, cr_revisions, and all extended attribute tables in the class hierarchy of a particular content type. This view may be used to query attributes when serving content.

Creating compound items

In many cases your content items will serve as containers for other items. You can include the set of allowable components as part of a content type definition. See Object Relationships for details.

---

templating@arsdigita.com

Last Modified: $‌Id: types.html,v 1.2.2.1 2019/08/10 18:09:52 gustafn Exp $