Data views are defined declaratively using XML according to a schema /META-INF/dataviews.xsd which is located inside cae-contentbeanservices.jar. Behind the scenes, subclasses of the application classes are generated. This process is transparent, as the remainder of the application should be written to the application class interfaces. Looking at a data view object’s class, however, it becomes obvious that it is actually an instance of a subclass of the original business class. How these classes behave, will be described later.

A sample XML data view definition using the example from above looks as follows:

<dataview appliesTo=”com.company.PageImpl”>
  <property name=”name”/>
  <property name=”description”/>
  <property name=”content”/>
  <property name=”parent” associationType=”composition”>
    <dataview appliesTo=”com.company.PageImpl” name=”forLinking”>
      <property name=”name”/>
    </dataview>
  </property>
</dataview>

This definition says: The default (no name attribute) data view of a PageImpl materializes the properties name, description, content and parent as fields where the latter is itself a bean of type PageImpl with data view forLinking (which is defined inline) applied. The association between the two data views is a composition. That means: the outer object embeds its private parent instance which is not shared with other beans, that is, the outer element owns the inner element exclusively. Specifically, no cache lookup is performed to retrieve the inner element, but it is always created when the outer element is created. The various association types will be described later.

This data view defines a view on Page content items that makes the following properties cached and quickly accessible:

All other properties are inherited from your *Impl classes and are therefore accessed dynamically. That does not mean that they are necessarily slow (there is a content item cache after all).

To use the defined data views, the data view factory dynamically constructs two subclasses of PageImpl, one for each data view definition. When the default data view is loaded, the data view factory will look into the cache with a key <Page content bean, null (default)> (Remember that the Page content bean’s equality is defined in terms of its content id). If the key is not in the cache, the factory will create an instance of the first subclass and load the properties description, content and name by invoking the business methods and storing the results. Furthermore, it will load parent (another lightweight PageImpl) and construct data view forLinking for it. To do so, it will not do a cache lookup but instantiate the corresponding second subclass of PageImpl directly. The result is stored as the materialized parent property of the result.

The generated code for the definition from above is roughly equivalent to the following:

class PageImpl$$ extends PageImpl {
  String name = super.getName();
  ...
  PageImpl parent =
   (PageImpl)dataviewFactory.lookupUncached(
        super.getParent(), “forLinking”);

  ...
  Page getParent() {
    return this.parent;
  }
  ...
}

It is possible to define data views with the same name for different classes. During the lookup for that name, the class of the object determines which data view definition is chosen – a dynamic dispatch very much like for content bean creation or the templates. This way, it is possible to apply a data view to a property value with a varying runtime class.

The default data view has a special meaning: it is the data view that is loaded at the beginning of a request when rendering the bean referenced by the URI. So this data view should correspond to the properties that the default view and its included fragment views require.