The Content Application Engine comes with a source code generator that reads your content type definition file and generates beans for each content type. The bean interfaces mirror the content properties, and the class hierarchy mirrors the content type hierarchy. After generating the code, you can modify and adapt it to your application’s needs.

Since you need the code generator only once (or even not at all, if you start over with CoreMedia Blueprint), there is no need for a dedicated application. Just add a temporary dependency

  <dependency>
    <groupId>com.coremedia.cms</groupId>
    <artifactId>bean-generator</artifactId>
    <scope>runtime</scope>
  </dependency>

to the POM file of your CoreMedia CAE module and build it. Then the code generator can be invoked as follows from within the WEB-INF directory of the CoreMedia CAE :

java -jar lib/bean-generator-<version>.jar

This gives you all available options of the generator as shown in Table 4.1, “Parameters of the Beangenerator”. You need to pass the location of your content type definition file(s), a package for the generated classes and a target directory for the source code. By default, the generator creates code with generics for link lists as comments in order to be compatible with legacy Java versions. When you have successfully created your content beans, you should delete the temporary dependency on bean-generator again so that your actual web application does not get unnecessarily bloated.

The meaning of the parameters of the Beangenerator is described in the next table.

Example

If you use the following call from the lib directory of your content application web application,

java -jar beangenerator.jar
-d /contentserver/config/contentserver/doctypes/menu-doctypes.xml
-o /output/classes
-c /properties/package.properties
-beanmapping /properties/contentbeans.xml
-e Picture
-generics

with the following package.properties file,

doctype.Dish.package=com.menusite.dish
package=com.menusite

this will generate interfaces, base classes and implementation classes for all document types of the menu site example except for the Picture document type. The document types are read from the /contentserver/config/contentserver/doctypes/menu-doctypes.xml file and the generated classes are written to the /output/classes directory.

The Dish document type belongs to the com.menusite.dish package while the other types are in the com.menusite package, this information is taken from the /properties/package.properties file. The bean mapping is written to the /properties/contentbeans.xml file. Generics are used which results in code like the following:

public List<? extends Dish> getContent() {
    List<Content> contents = getContent().getLinks("content");
    return createBeansFor(contents, Dish.class);
}

Structure of the Generated Code

When you inspect the generated classes, you will find that three files per document type are generated:

The interface is what you should use in other classes, “*Base” contains the repository access code and “*Impl” is the actual class that is instantiated. This class is the place for you to modify. When a document type inherits from another type, its "*Base" class inherits the "*Impl" class of its parent. This way, it inherits the custom extensions made for the supertype. For content types that do not have a parent, the "*Base" class inherits from a framework class AbstractContentBean that defines the underlying content bean, factory, equality and hash code as well as a few convenience methods.

Note

The generated code may not compile under some circumstances, due to naming conflicts, for example. A content property named ‘content’ will clash with the method #getContent inherited from ContentBean. In this case you should rename the generated getters in the interface and the *Base class.

The "*Base" class contains property getters for every user-defined property in the corresponding content type. Getters are not generated for metadata such as name or creation date. The property types are mapped to Java as follows:

You are free to modify the generated code. For example, you can do the following:

When extending, you should not declare any fields in a content bean except for read-only, immutable service references.