| Red Hat Content Management System 6.1: CMS Developer Guide | ||
|---|---|---|
| Prev | Chapter 5. Content Type Separation | Next |
To make a content type available for use, it must be registered with the CMS. There are a number of tasks to accomplish to register a content type, including a ContentType, AuthoringKit, and several AuthoringStep domain objects, loading the data model and integrating the XSL styling. While this can be accomplished programmatically, the recommended approach is to write an XML content type definition file and place it in the directory $WEBAPP/WEB-INF/content-types. Within this directory, the file should be in a directory matching the package name of the content type and the file should match the name of the primary content type. So for the BankNote content type, the file would be $WEBAPP/WEB-INF/content-types/com/example/moneymachine/cms/contenttypes/\ BankNote.xml. Upon server startup, all XML files found in this directory will be processed registering the content types with the CMS.
We'll now look at each element in turn. For reference purposes, the full schema for this definition file is at Section 5.4.1 Content Type Definition Schema, along with an example for the Article content type in Section 5.4.2 Content Type Definition Example.
The root element in the definition is <ctd:content-types>. This is a container for one or more <ctd:content-type> elements - one for each type being defined. Typically you would only define one content type in each file, however, if you had a pair of co-dependant content types you would define them both in a single file to ensure they are both loaded together. The attributes on this tag are used to specify the namespace for the elements which follow and schema location so that the processor can validate the document.
<ctd:content-types xmlns:ctd="http://rhea.redhat.com/schemas/cms/\
content-types"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://rhea.redhat.com/schemas/cms/\
content-types content-types.xsd">
... content types ...
</ctd:content-types> |
The <content-type> element contains four attributes. The label is a short title of the content type, which is typically displayed in a form for creating a content type. The description is a more verbose version of the label, allowing up to 4000 characters of text. The objectType refers to the persistence object type (as defined in your PDL file). The classname attribute should specify the Java domain class for the content type. An example definition for the Article type looks like:
<ctd:content-type label="Article"
description="An article type with image"
objectType="com.arsdigita.cms.contenttypes.Article"
classname="com.arsdigita.cms.contenttypes.Article">
... authoring kits ...
</ctd:content-type> |
The <content-type> element will contain a single <authoring-kit> element. The only attribute an authoring kit has is createComponent which should specify the Java classname of the Bebop component used to create an instance of the content type.
<ctd:authoring-kit createComponent="com.arsdigita.cms.ui.authoring.\
PageCreate">
... authoring steps ...
</ctd:authoring-kit> |
An <authoring-kit> element will contain multiple <authoring-step> elements. The label attribute is the short title of the authoring step, typically used when displaying a link to the step. The description attribute is a longer version of the label that could, for example, be displayed as a popup hint on the link to an authoring step. The component attribute specifies the Java classname for the bebop component that forms the authoring step. The final ordering attribute is used to determine the order in which to display multiple steps. Each authoring step defined must have a distinct value for its ordering attribute, and they are typically assigned in a monotonically increasing sequence.
<ctd:authoring-step label="Article Properties"
description="Edit the basic article properties"
component="com.arsdigita.cms.contenttypes.ui.\
ArticlePropertiesStep"
ordering="1"/> |