loading table of contents...

Blueprint Developer Manual / Version 2107

Table Of Contents

4.4.2 Extending Content Types

Developing a new software almost always starts by analyzing the domain model. This is not different for CoreMedia CMS. Here the domain model is the source for modeling the content type model. The content type model is the backbone of CoreMedia CMS as it describes what content means to you. Read Chapter 4, Developing a Content Type Model in Content Server Manual for details on the content types.

Basically, there are two places within the Blueprint workspace you may use if you define your own content type model or extend the Blueprint's one. You will learn both of them by defining a new content type CMHelloWorld as a child of CMTeaser within a new file mydoctypes.xml as follows:

<?xml version="1.0" encoding="ISO-8859-1" ?>

 <ImportGrammar Name="coremedia-richtext-1.0"/>
 <ImportDocType Name="CMTeaser"/>

 <DocType Name="CMHelloWorld" Parent="CMTeaser">
   <StringProperty Name="message" Length="32"/>
Defining content types in contentserver-blueprint-component

The first and a little easier way of defining CMHelloWorld is to put the new file mydoctypes.xml shown above into the directory apps/content-server/modules/server/contentserver-blueprint-component/src/main/resources/framework/doctypes/my/. It is good style to create a subfolder under doctypes for your customization, here named "my".

After doing so, you can test your new content type. To do so, you have to build the contentserver-blueprint-component module and the content-server-app module as follows. Remember to stop the server if you have not already.

$ cd apps/content-server/modules/server/contentserver-blueprint-component
$ mvn clean install
$ cd apps/content-server/spring-boot/content-server-app
$ mvn clean install

Now, start the Content Management Server application and take a look into its log file. You should see the following message, telling you that the Content Server created a new database table for the new content type.

[INFO]  SQLStore - DocumentTypeRegistry: creating table:
isApproved_ TINYINT, isPublished_ TINYINT, editorId_ INT,
approverId_ INT, publisherId_ INT, editionDate_ DATETIME,
approvalDate_ DATETIME, publicationDate_ DATETIME,
"locale" VARCHAR(32), "masterVersion" INT, "keywords" VARCHAR(1024),
"validFrom" DATETIME, "validFrom_tz" VARCHAR(30), "validTo" DATETIME,
"validTo_tz" VARCHAR(30), "segment" VARCHAR(64), "title" VARCHAR(512),
"teaserTitle" VARCHAR(512), "notSearchable" INT, "message" VARCHAR(32),
PRIMARY KEY (id_, version_),  FOREIGN KEY (id_) REFERENCES Resources(id_))
Using a Separate Module in the Context of an Extension

The second possibility is the more flexible way. You build your own module in the context of an extension. The following steps assume that an extension module my-extension already exists and requires a new content type. Proceed as follows:

  1. Create a new subfolder my-extension-server in the apps/content-server/modules/extensions/my-extension directory.

  2. Create a pom.xml file and add the following contents.:

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns=""
  3. Adjust the groupId and artifactId of the parent declaration according to your project settings.

  4. Add this module's Maven coordinates to the Extension Descriptor of the extension.

  5. Create the subfolder src/main/resources/framework/doctypes/myextension.

  6. Copy the content type definition file from above into the folder created in the last step.

  7. Refer to Section 4.2.1, “Removing Optional Components” to enable the extension.

Search Results

Table Of Contents

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.