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.
A content item typically consists of two components:
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.
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.
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.
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.
Last Modified: $Id: types.html,v 188.8.131.52 2001/03/13 22:59:26 ben Exp $