Adobe® LiveCycle® Data Services ES 2.6 Developer Guide

Managing class hierarchies

If you have strongly typed Java classes that extend each other and you want to manage both the supertype and the subtype, there are two strategies you can use. You can use the single destination approach in which one destination manages the entire type hierarchy, or you can use the multiple destinations approach in which you define a separate destination for each managed class in the hierarchy. You cannot mix these two approaches for the same class hierarchy.

You can only use the single destination approach if all of the classes in the class hierarchy have the same association properties. If a subclass introduces a new association, you define a separate destination for each concrete class in the class hierarchy. In both strategies, the identity properties must be the same for all managed classes in the type hierarchy. Additionally, in both approaches there must be ActionScript classes defined for each concrete Java class.

For the multiple destinations approach, you also specify the item-class element for each destination to refer to the entity class name of the object associated with the destination. You should also specify the extends attribute of the metadata element to refer to the super type destination. When using the multiple destinations approach, the following rules apply:

  • The fill or getItem method can return instances of the class defined for this association (if any) or any subclasses of that destination.
  • The updateItem, createItem, or deleteItem methods are called on the assembler defined for the most specific destination defined for the given class.
  • Subclasses automatically inherit identity properties and associations and do not have to be redeclared.
  • If you do not define a separate assembler instance (using a source, or factory element), the assembler instance for the extends destination is used for the child destination.

When you use the extends attribute of the metadata element in a destination, you use the item-class element to bind each destination to a specific Java class; for information about the item-class element, see Data Management Service clients. You also must have an ActionScript class mapped to each Java class so the type is preserved as objects are sent to the client.

The instances returned by your assembler from a given destination should be instances managed by this destination or the destination of a subtype. An extended destination inherits the identity properties and associations of its base type. It can extend more than one destination, but those destinations must have the same identity properties.

If you want to use one assembler instance for an entire class hierarchy, make sure that you use the attribute-id element so that each destination uses the same attribute name to store the class and also ensure the source and scope properties are copied among the destinations.

Single destination approach for managing class hierarchies

The following examples show the source code of Java and ActionScript classes and destination configuration for the single destination approach.

Foo.java

package samples.oneDestExtends;

public class Foo 
{
    public Foo() {}

    public int id;

    public int property1;
    public int property2;

    public Foo selfReference; // my store ref to instance of Foo or Bar 
}

Bar.java

public class Bar extends Foo
{
    public int property3;
    public int property4;

    // NOTE: cannot add additional managed associations in the subclass using this approach
}

Foo.as

[Managed]
[RemoteClass(alias="samples.oneDestExtends.Foo")]
public class Foo implements java.io.Serializable
{
    public function Foo() {}

    public var id:int
    public var property1:int
    public var property2:int

    public var selfReference:Foo;
}

Bar.as

[Managed]
[RemoteClass(alias="samples.oneDestExtends.Bar")]
public class Bar extends Foo
{
    public function Bar() 
    {
        super();
    }

    public var property3:int;
    public var property4:int;
}

data-management-config.xml

...
<destination id="oneDestExtends.foo">
    <properties>
        <metadata>
            <identity property="id"/>
            <many-to-one property="selfReference" destination="oneDestExtends.foo"/>
        </metadata>
        <source>oneDestExtends.FooAssembler</source>
    </properties>
</destination>
...

<!-- No destination required for Bar in this approach -->

Multiple destination approach for managing class hierarchies

The following example code shows the Java class source code and destination configuration for an application that uses the multiple destinations approach. In this case, a Node class has a ParentNode subclass. The Node class has an association called parent of type ParentNode and the ParentNode class adds an association called children of type Node.

Node.java:

package samples.multiDestExtends;

public class Node implements java.io.Serializable
{
    public Node() {}

    public int id;

    public ParentNode parent;
}

ParentNode.java:

public class ParentNode extends Node
{
    // Contains either Node or ParentNode instances
    public List children = new LinkedHashSet();
}

data-management-config.xml

...
<destination id="multiDestExtends.Node">
    <properties>
        <metadata>
            <identity property="id" undefined-value="-1"/>
            <many-to-one property="parent"
                destination="multiDestExtends.ParentNode" lazy="true"/>
        </metadata>

        <item-class>samples.multiDestExtends.Node</item-class>
        <source>samples.multiDestExtends.NodeAssembler</source>
        <scope>application</scope>
    </properties>
</destination>

<destination id="multiDestExtends.ParentNode">
    <properties>
        <metadata extends="multiDestExtends.Node">
            <one-to-many property="children"
                destination="multiDestExtends.Node" read-only="true"
                lazy="true" page-size="2"/>
        </metadata>
        <item-class>samples.multiDestExtends.ParentNode</item-class>

<!-- inherits same assembler instance by default -->
    </properties>
</destination>

Node.as:

[RemoteClass(alias="samples.treepagingjdbc.Node")]
[Managed]
public class Node
{
    public var id : int;
    public var name:String;
    public var parent:ParentNode;
        
    public function Node()
    {
        super();
    }
}

ParentNode.as

import mx.collections.ArrayCollection;

[RemoteClass(alias="samples.treepagingjdbc.ParentNode")]
[Managed]
public class ParentNode extends Node 
{
    public var children:ArrayCollection; 

    public function ParentNode()
    {
        super();
    }
}


 

Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/dms_managedobjects_5.html