## 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, not `cr_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 compund 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.1.1.1 2001/03/13 22:59:26 ben Exp $