Fixing the ADF Faces Tree Model Binding – Leaf Nodes without Folder Icon

Some of my past writings on this blog were on ADF Faces and more specifically on the ADF Faces Tree component. When bound to an ADF Data Control, the Tree component has a very annoying habit: every node is shown at all times as having details. Even leaf nodes with no detail nodes whatsoever are displayed as if they were container nodes; this is even the case when the node has been expanded and clearly demonstrates an overwhelming lack of children. You can see an example of this behavior here – for an HRM tree with DEPT and EMP based nodes:

 

 

In this article, I will describe a solution to this problem, created with help from Steve Muench and in collaboration with Rob Brands. It turns out to be an exercise in the ADF Model framework and is not suitable for the faint of heart. See for more background on the problem and the road to a solution my previous article Building an ADF Faces Tree Component with mixed (DEPT and EMP) nodes in 5 minutes using JHeadstart 10.1.3.

Let’s first create a simple application with a tree component, just like the one shown above:

Creating a Data Driven Web Application with ADF Tree Component 

In rapid succession the steps to get to the point where we have a ADF Tree component in our Web Application, based on database tables, with that annoying every-node-is-a-container behavior:

1. Start JDeveloper 10.1.3

2. Create New Application, new Project with Web Technology Template (ADF BC and JSF); a Model and a ViewController project are created

3. In the Model Project:

 

• Create new Business Components from Tables: create or select a connection to the SCOTT schema, select tables EMP and DEPT, create default EntityObjects and ViewObjects, close the wizard
• Edit the Emp and Dept EntityObjects: set Empno respectively Deptno to be the Primary Key attribute and uncheck the Primary Checkbox for the RowId attribute in both EntityObjects
• Edit the EmpView and DeptView ViewObjects and remove the RowId attribute from both
• Create ViewLinks from Dept to Emp (based on DeptView.Deptno = EmpView.Deptno) and from Emp to Emp (based on Emp.Empno = Emp.Mgr)
• Edit the Application Modul’s Data Model: add EmpView under DeptView – based on the ViewLink just created

 

4. In the View Controller project:

Create a New JSF JSP page

Drag the AppModuleDataControl.DeptView collection to the new untitled.jspx page. Select Trees, ADF Tree from the dialog

In the Tree Binding Editor, define two rules:

The First Rule establishes the root-nodes for the tree, based on the DeptView Collection, with Dname for the Node Label and EmpView as the accessor for the first (and only) branch with childnodes.

 

The Second Rule introduces Emp nodes into the tree, using Ename for the Node Labels and having it’s own branch of additional Emp childnodes based on the EmpView branch rule accessor.

 

 

Now the application is ready and can be run. The result is shown at the top of this article. All nodes – regardless of whether they have children or not – are shown with the Folder icon. This will invite users to expand nodes that turn out to have no child nodes and is misleading as well as annoying.

Extending the ADF Framework with a smarter model

In the previous articles – referred in the introduction – I have explained what the reasoning was for the ADF development team to implement the current behavior: inspecting every nodes to find out from the ADF Model and underlying iterator whether any children exist for that node was deemed far too much of a performance load. We will see now how we can override this somewhat paternalistic attitude for situations where that load is not so heavy (small tables for example) or we have smarter way of finding out whether there are children or not.

This approach requires us to implement our own binding-class for trees and register it somehow with our application. Fortunately we can use subclassing of existing ADF classes to a large extend and end up writing very little code of our own.

The starting point is the ADFBindingFilter that is run at the very start of the application to perform certain initialization steps. Among these steps is the instantiation and registration of several factory classes that will be used by the ADF Framework to get implementations of binding classes. We will have to override the default ADFBindingFilter class to register our own extended factory.

The ADFBindingFilter is registered as Filter in the web.xml file; we will specify our own Filter instead (and develop that Filter class in just a moment):

    <filter>
        <filter-name>adfBindings</filter-name>
        <filter-class>nl.amis.view.MyADFBindingFilter</filter-class>
    </filter>

The BindingFilter we need is largely the same as the ADFBindingFilter; we just need a small override to register our own BindingDefFactoryImpl instead of the hard-coded one shipped with ADF Faces: FacesBindingDefFactoryImpl

package nl.amis.view;
import oracle.adf.model.servlet.ADFBindingFilter;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import oracle.jbo.uicli.mom.JUMetaObjectManager;

public class MyADFBindingFilter extends ADFBindingFilter  {
    public void init(FilterConfig filterConfig) throws ServletException {
      super.init(filterConfig);
      JUMetaObjectManager.setControlDefFactory(new MyCustomBindingDefFactoryImpl());
      JUMetaObjectManager.getJUMom().registerDefinitionFactory(
                 "http://xmlns.oracle.com/adfm/uimodel",new MyCustomBindingDefFactoryImpl());
    }
}

 

The FactoryImpl we register – MyCustomBindingDefFactoryImpl – is our own class, that extends of course from one of the standard ADF Classes:

package nl.amis.view;

import oracle.jbo.uicli.binding.JUBindingDefFactoryImpl;

import oracle.adf.model.binding.DCDefBase;

import oracle.adfinternal.view.faces.model.binding.FacesCtrlActionDef;
import oracle.adfinternal.view.faces.model.binding.FacesCtrlAttrsDef;
import oracle.adfinternal.view.faces.model.binding.FacesCtrlHierDef;
import oracle.adfinternal.view.faces.model.binding.FacesCtrlListBinding;
import oracle.adfinternal.view.faces.model.binding.FacesCtrlListDef;
import oracle.adfinternal.view.faces.model.binding.FacesCtrlRangeDef;

import oracle.jbo.mom.xml.DefElement;
import oracle.jbo.uicli.mom.JUTags;
import nl.amis.view.MyFacesCtrlHierBinding;

import oracle.adfinternal.view.faces.model.binding.MyFacesCtrlHierDef;

public class MyCustomBindingDefFactoryImpl extends JUBindingDefFactoryImpl {

    public DCDefBase createDefinition(DefElement element) {
        //copied from FacesBindingDefFactoryImpl
        String sElement = element.getElementName();
        if (sElement.equals(JUTags.PNAME_table)) {
            return new FacesCtrlRangeDef();
        } else if (sElement.equals(JUTags.PNAME_tree)) {
            // here is
 my new code!!!!
            ret
urn new MyFacesCtrlHierDef();
        } else if (sElement.equals(JUTags.PNAME_listOfValues) || 
                   sElement.equals(JUTags.PNAME_list)) {
            FacesCtrlListDef def = new FacesCtrlListDef();
            def.setSubType(DCDefBase.PNAME_ListSingleSel);
            def.setControlBindingClassName(FacesCtrlListBinding.class.getName());
            //       def.setStaticList(false);
            return def;
        } else if (sElement.equals(JUTags.PNAME_attributeValues)) {
            return new FacesCtrlAttrsDef();
        } else if (sElement.equals(JUTags.PNAME_methodAction) || 
                   sElement.equals(JUTags.PNAME_action)) {
            return new FacesCtrlActionDef();
        }
        return super.createDefinition(element);
    }
}

 

This class overrides just a single method: createDefinition. This method is invoked whenever the ADF Binding layer needs to instantiate a Model Binding component for use in a Page as instructed by the PageDefinition. My class contains some code copied from FacesBindingDefFactoryImpl with one change: the DCDefBase returned for a Tree element.

The implementation of the MyFacesCtrlHierDef is very simple: it only returns the correct – MyFacesCtrlHierBinding instead of FacesCtrlHierBinding – DCControlBinding I want to use for tree.

package oracle.adfinternal.view.faces.model.binding;
import oracle.adf.model.binding.DCBindingContainer;
import oracle.adf.model.binding.DCControlBinding;
import oracle.jbo.uicli.binding.JUCtrlHierDef;
import oracle.jbo.uicli.binding.JUIteratorBinding;


/**
 * This definition class provides instances of FacesCtrlHierBinding
 * for tree bindings.
 */
public final class MyFacesCtrlHierDef extends JUCtrlHierDef
{
  public MyFacesCtrlHierDef()
  {
  }

  protected DCControlBinding createControlBindingInstance(Object control, DCBindingContainer formBnd)
  {
    return new MyFacesCtrlHierBinding(control, 
                                    (JUIteratorBinding)getIterBinding(formBnd), 
                                    getAttrNames(),
                                    getTypeBindings());
  }
} 

The real logic now finally can be written in the MyFacesCtrlHierBinding class – largely a copy from the (final!) class FacesCtrlHierBinding. I only show here the method I have changed after copying all code from FacesCtrlHierBinding:

    public boolean isContainer()
    {
      JUCtrlHierNodeBinding node = _getRowData();
      // LJ: test if there is binding for an attribute called IsContainer
      //     if there is one, we assume it will return a String with value N
      //     whenever a node is NOT a container - has no children.
      //     If such an attribute binding does not exist, we will fall back 
      //     to default behavior, which is always return true;
      
      // to implement:
      // - add an attribute IsContainer (type String) to your ViewObject
      // - implement the getIsContainer() method in the ViewRowImpl class
      // - add the attribute to the PageDefinition (UI Model):
      //   ...
      //     <Item Value="IsContainer"/>
      //   </AttrNames>

      if (node.getRow().getAttributeIndexOf("IsContainer") > -1) {
        return (!"N".equalsIgnoreCase((String)node.getAttribute("IsContainer")));
      }
      return true;
    }
 

The isContainer method is called for every node to determine whether the Folder icon should be displayed for the node. The default implementation from the ADF team always returns true. My implementation does the following: it inspects the current Row to find out whether it contains an Attribute called IsContainer. If so, it will retrieve the value of that Attribute and check if it is N. Only if the value is available and it is equal to N will the method assume that the node has no children and should not be expandable and labeled with the folder icon.

To leverage this implementation of isContainer(), we have to do the following:

1. Add an Attribute IsContainer to the ViewObject(s) underlying the tree
2. Implement the getIsContainer method in the ViewRowImpl class(es) for these ViewObject(s) – make them return N whenever the node has no children
3. Add the IsContainer attribute to the PageDefinition of the page that contains the tree

When this is in place, restart the application. If all still works as before, we probably have done the right things (or we have done nothing at all). Let’s now proof the pudding:

1. Add a new transient Attribute IsContainer to the EmpView ViewObject (type is String)

2. Generate the ViewObjectRowImpl for EmpView

3. Implement the getIsContainer method in the EmpViewRowImpl class:

    public String getIsContainer() {
        return getJob().equalsIgnoreCase("MANAGER")?"Y":"N";
    }

4. Add the IsContainer attribute to the PageDefinition file:

...
<nodeDefinition DefName="model.EmpView" id="EmpViewNode">
  <AttrNames>
    <Item Value="Ename"/>
    <!-- the next line was added! -->
    <Item Value="IsContainer"/>
  </AttrNames>
  <Accessors>
    <Item Value="EmpView"/>
  </Accessors>
...

5. Run the application:

Here we see the desired result: any node (Employee) that specifies IsContainer equals N (all employees who are not a MANAGER) does not have the folder icon and the option to expand! 

To get rid of the Y and N values in the Employee node labels, we have to slightly enhance the JSPX page. We implement a somewhat sophisticated nodestamp facet:

<f:facet name="nodeStamp">
  <af:switcher facetName="#{node.hierType.name}">
    <f:facet name="DeptViewNode">
      <af:outputText value="#{node.Dname}"/>
    </f:facet>
    <f:facet name="EmpViewNode">
      <af:outputText value="#{node.Ename}"/>
    </f:facet>
  </af:switcher>
</f:facet>

 

And beyond… 

Of course it should be fairly simple to implement different types of
logic, for example code that may not know in advanced whether a node
has children, but that will remember when the node has been expanded
and has been found to not have children.

Resources

Download the completed Hrm Application with extended Tree model: HrmTreeNoLeafNodeSolution.zip