UPDATE: There have been a few requests for a more complete source code example. The following link is to a demo application of the concepts from this entry, and the source code in this entry has been updated to reflect the content of the demo. Recursive Tapestry Tree Demo Application

We use Tapestry 5 at work.  Tapestry is a wonderful, efficient, and powerful framework, but like any piece of technology, there are headaches.  The headache we had this past week was how on earth to render a tree of of components where we have to dynamically select the component depending upon the current context within the tree.  Here’s the approach we uncovered using three components: a component acting as a container for the tree, another to render individual nodes of the tree (contextually subclassed for different nodes), and a custom delegate component (to turn off parameter caching).

The Container Component

The container component maintains stateful tree information while rendering the tree, and selects the component to render for the current node of the tree.

Here is the container’s template.

<?xml version="1.0" encoding="UTF-8"?>
<ul xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd">
 
    <!-- The custom delegate to the component to render based on the context of the current node. -->
    <t:nodedelegate to="currentNodeRenderer"/>
 
    <t:block>
        <!-- This block contains a set of components to delegate rendering to based on the current node. -->
        <div t:id="blackNode">
            <!-- Delegate to the child component to render.  This replaces the component's body. -->
            <t:nodedelegate to="currentNodeRenderer"/>
        </div>
 
        <div t:id="redNode">
            <t:nodeDelegate to="currentNodeRenderer"/>
        </div>
 
    </t:block>
 
</ul>

And the container’s implementation.

public class Tree {
 
    @Parameter(required = true)
    private Node node;
 
    @Component(id = "blackNode", parameters = {"node=currentNode", "childPosition=currentChildPosition"})
    private RenderBlackNode blackNode;
 
    @Component(id = "redNode", parameters = {"node=currentNode", "childPosition=currentChildPosition"})
    private RenderRedNode redNode;
 
    private Node currentNode;
 
    private Map<Node, Integer> childPositions;
 
    public Node getCurrentNode() {
        return currentNode;
    }
 
    public void setCurrentNode(final Node node) {
        // set the initial child position for the node to 0 if it has not been seen yet.
        if (!childPositions.containsKey(node)) {
            childPositions.put(node, 0);
        }
        this.currentNode = node;
    }
 
    public int getCurrentChildPosition() {
        return childPositions.get(this.currentNode);
    }
 
    public void setCurrentChildPosition(final int pos) {
        this.childPositions.put(currentNode, pos);
    }
 
    /**
     * Selects the Node component to render based on the currentNode type.
     *
     * @return the component to render the current node
     */
    public BaseRenderNode getCurrentNodeRenderer() {
        BaseRenderNode object = null;
        if (currentNode instanceof BlackNode) {
            object = blackNode;
        }
        else if (currentNode instanceof RedNode) {
            object = redNode;
        }
        return object;
    }
 
    void setupRender() {
        childPositions = CollectionFactory.newMap();
        setCurrentNode(node);
    }
}

The Custom Delegate

This was the crucial component that unlocked our ability to build the tree.  As you can see above, the delegate will be encountered with every node in the tree, and since the type of a child node may change, the delegate needs to be able to change the component that it references.  The built-in Delegate component in Tapestry 5 cannot do this, since the “to” parameter is cached.  We needed to build a custom Delegate component identical to the built-in one but with the “to” parameter uncached so that the delegate would query the container for what component to render each time the delegate is encountered.

The Node Component (with subclasses)

Each type of node in the tree needs its own component type, but they all extend from an identical base component that is responsible for changing the current node to render as well as updating the index of the next child node to render.

Each subcomponent needs to share this basic structure:

<?xml version="1.0" encoding="UTF-8"?>
<div xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd">
    <!-- The body is replaced with component(s) for the child nodes. -->
    <t:body/>
</div>

Here’s the base Node component.

public class BaseRenderNode {
 
    @Parameter(required = true, cache = false)
    private Node node;
 
    @Parameter
    private int childPosition;
 
    @SetupRender
    boolean setup() {
        // prevents rending with the node parameter is null.
        return node != null;
    }
 
    @BeforeRenderBody
    boolean beforeChild() {
        // the node  has children, render the body to render a child
        final boolean render = node.getChildren().size() > 0;
 
        if (render) {
            // sets the container's currentNode to the node's child at the given index.
            node = node.getChildren().get(childPosition);
        }
        return render;
    }
 
    @AfterRenderBody
    boolean afterChild() {
        // increment the child position, afterRender on the child will have the container's currentNode set back to the node before the body was rendered.
        childPosition = childPosition + 1;
        // return true on last child index, finishing the iteration over the children, otherwise re-render the body (to render the next child)
        return node.getChildren().size() <= childPosition;
    }
 
    @AfterRender
    void after() {
        // set the currentNode to the parent after render (pop the stack)
        if (!node.isRoot())
            node = node.getParent();
    }
}

Conclusion

We have seen how a tree-like structure can be rendered through Tapestry 5.  Tapestry’s ability to dynamically render static templates made this possible, but we needed to turn off a caching optimization in the Delegate component in order to increase the dynamism.

Hibernate and DataNucleus (JDO2) are arguably the two most substantial persistence frameworks in the open source ecosystem.  I have worked with DataNucleus quite a bit on the side, and I am now finding an opportunity to use Hibernate during my day job.

I have now spent enough time using Hibernate to appreciate the approach that DataNucleus takes using bytecode enhancement in comparison to Hibernate’s proxies.  Essentially, I am finding myself having to appease Hibernate’s view of the world in unexpected ways where I would like to leave my code alone. Two problem cases have come up so far that I would not have encountered with DataNucleus: using instanceof with type hierarchies and implementing equals.  In both of these case, bytecode enhancement would leave my Java code to work just as I expected; but instead, I have to deal with an extra layer of indirection where I was expecting to deal directly with my objects.

Type hierarchies and instanceof

Lets say that I have the following type hierarchy:

public interface Transformer { ... }
 
public interface Autobot extends Transformer { ... }
 
public interface Decepticon extends Transformer { ... }

Obviously, there are times that I may be given an instance of type Transformer where I want to distinguish between an Autobot and a Decepticon using instanceof.  However, if I am persisting these instances with Hibernate, and I receive a proxy to the persisted entity, I cannot use instanceof to determine the type of the instance I am dealing with.  In Hibernate, the entity instance could well be an Autobot, but the returned proxy to the entity will implement both the Autobot and the Decepticon types.

In order to determine the instance type I am dealing with, I have to either unwrap the proxy or turn off lazy loading.  Both of these are undesirable solutions.  Unwrapping the proxy adds extra persistence operations outside of the persistence tier of your application, which violates a clean separation of concerns.  And of course, there is a performance hit for turning off lazy loading.  I wouldn’t have to use either of these undesirable solutions with DataNucleus.

Implementing equals

This problem seems well documented within the Hibernate community, but it is still an annoyance and evidence of how Hibernate’s design forces you to alter expected Java constructs to fit Hibernate’s needs.  If you want an equals method to play friendly with Hibernate proxies you need to.

• Do comparisons on properties instead of fields. If you compare on fields, the proxy may return null, comparing on properties will initialize the proxy and return the expected result.
• Use instanceof comparison instead of class equality.  The type of the proxy is not equal to the type of the entity, but rather extends the type of the entity.
• Compare to the interface instead of the implementing class. You need to do this if you are using interface proxies instead.

All of the above break the expected construct of the equals method, and DataNucleus does not force you to make any of these concessions.

Conclusion

Obviously, I’m still expanding my knowledge in the Hibernate way of the world, but from just these two headaches I have had with Hibernate, DataNucleus’ approach of using bytecode enhancement looks much superior to the proxying that Hibernate does.