Creating Multi-Type Node Children and Child Node labels in ADF Faces Tree Component

As you may have gathered from some recent posts, we are in the process of developing an ADF Faces/ADF Business Components application in a project for one of the largest cities in The Netherlands. We have a requirement for the tree – one of the key navigation components in this application: it should be able to show child nodes from various data sources  (ViewObjects) under one parent and it should show child node labels under the parent before showing the children. The latter means that under the Department node we do not want to immediately get all Employee children, but instead first have the label Employees under which all Employee children are listed.

I want to achieve something like:

However, the ADF Faces Tree Component is based on the FacesCtrlHierBinding and the FacesModel classes when we use the ADF Binding framework as an intermediary between the Tree and the Model. And this ADF Binding Model does not allow for child nodes from multiple ViewObjects. And child node labels are not catered for – or at least not without a workaround. This article obviously will discuss that workaround.

If we cannot have the ADF Model Tree component come to our ViewObjects, we will have to be flexible on our end, I am afraid. So the crux of the solution is the development of a set of ViewObjects that provide the data in our tree. Most specifically:

1. we will have one ViewObject for each level in the tree (HrmTreeFirstLevelView, HrmTreeSecondLevelView, …)
2. each tree level ViewObject will return the same five attributes: NodeKey, NodeType, NodeLabel (what is displayed in the tree component), ParentKey and ParentType (the latter two attributes required to link child nodes to their parents)
3. we will have ViewLinks between each pair of ViewObjects, from FirstLevel to SecondLevel, from SecondLevel to ThirdLevel and so on
4. the application module’s data model will have a nested hierarchy of all TreeLevel views, linked by the view links
5. in our JSF JSP page we will set up a Tree Component based on the ViewObject(Usage) hierarchy

ViewObjects for the tree

As stated before, we need to create a View Object for each level in the tree. We need to carefully design the tree and know at each level which nodes we want to have, both static and (dynamic) data-driven. For each node (type) we need to define its key and type as well as its link to the parent (also through key and type). Finally we determine the label to be displayed to the end user. All our ViewObjects will be read only, based on a custom SQL statement.

The first level in the tree typically contains static node labels, indicating the various categories of nodes available in the tree. The HrmTreeFirstLevelView is based on the following SQL Statement:

select node_key
,      node_type
,      node_label
,      parent_key
,      parent_type
from   ( select 1 node_key
         ,      'root' node_type
         ,      'Departments' node_label
         ,      null parent_key
         ,      null parent_type
         from   dual
         UNION ALL
         select 2 node_key
         ,      'root' node_type
         ,      'Employees' node_label
         ,      null parent_key
         ,      null parent_type
         from   dual
         UNION ALL
         select 3 node_key
         ,      'root' node_type
         ,      'Locations' node_label
         ,      null parent_key
         ,      null parent_type
         from   dual       
      ) 

The second level tree adds the first dynamic, data driven nodes. Under the First Level Employees Node, we want to have all Employees in the EMP table. Under the Departments node we likewise want to see all Departments in DEPT and under Locations we want to get a listing of all distinct Locations values in DEPT. We also need to indicate for each of these nodes how they link to their Parents from the HrmTreeFirstLevelView. The SQL Statement for this ViewObject is now:

select node_key
,      node_type
,      node_label
,      parent_key
,      parent_type
from   ( select empno node_key
         ,      'emp' node_type
         ,      ename node_label
         ,      2 parent_key
         ,      'root' parent_type
         from   emp
         UNION ALL
         select deptno node_key
         ,      'dept' node_type
         ,      dname node_label
         ,      1 parent_key
         ,      'root' parent_type
         from   dept
         UNION ALL
         select deptno node_key
         ,      'loc' node_type
         ,      loc node_label
         ,      3 parent_key
         ,      'root' parent_type
         from   dept       
      ) 

The Third Level adds labels for Salesmen and Clerks per Department and Subordinates under Employees:

select node_key
,      node_type
,      node_label
,      parent_key
,      parent_type
from   ( select empno node_key
         ,      'subLabel' node_type
         ,      'Subordinates' node_label
         ,      empno parent_key
         ,      'emp' parent_type
         from   emp
         UNION ALL
         select deptno node_key
         ,      'salesmenLabel' node_type
         ,      'Salesmen' node_label
         ,      deptno parent_key
         ,      'dept' parent_type
         from   dept
         UNION ALL
         select deptno node_key
         ,      'clerksLabel' node_type
         ,      'Clerks' node_label
         ,      deptno parent_key
         ,      'dept' parent_type
         from   dept
      ) 

The last level discussed in this article will show those Salesmen, Clerks and Subordinates, using the following SQL Statement:

select node_key
,      node_type
,      node_label
,      parent_key
,      parent_type
from   ( select empno node_key
         ,      'emp' node_type
         ,      ename node_label
         ,      mgr parent_key
         ,      'subLabel' parent_type
         from   emp
         UNION ALL
         select empno node_key
         ,      'salesmenLabel' node_type
         ,      ename node_label
         ,      deptno parent_key
         ,      'salesmenLabel' parent_type
         from   emp
         where job ='SALESMAN'
         UNION ALL
         select empno node_key
         ,      'emp' node_type
         ,      ename node_label
         ,      deptno parent_key
         ,      'clerksLabel' parent_type
         from   emp
         where  job = 'CLERK' 
      ) 

note: the NodeKey and NodeType attributes are both Key Attributes for these ViewObjects. Also note that in this article I quit with these four levels but that is not because of any sort of limitation – you can continue for pretty much as long as you like. Finally: I did not do it in this example, but there is no reason why you could not mix Static Labels and Dynamic Data in the same level ViewObject.

The ViewLinks to tie the tree levels together

The ADF Tree is driven by "rules" that hinge on ViewObjects (DataControl Collections) tied together throug
h ViewLi
nks. Each level in our tree hierarchy is tied to the next through a ViewLink. And each of these ViewLinks is constructed in the same manner:

The higher level is the Source, the lower (child) level the target. The join is on NodeKey to ParentKey and NodeType to ParentType. I have used a naming convention like HrmTreeFirstSecondViewLink, HrmTreeSecondThirdViewLink etc. for clarity.

Creating the Application Module’s Data Model

All ViewObjects we want to use to base our tree on must be included in the Data Model for the Application Module. In fact, they must be nested in that data model in the same way we want to nest them in the tree in the user interface: 

Note that this is an excellent moment to the tree model we have now set up, using the ADF BC ApplicationModule Tester , from the RMB menu on the Application Module.

Creating the JSF page with the ADF Faces Tree Component

Well, all that is left to do is creating the page we so much desired. Simply create a new JSF JSP page, accept all defaults or change them as you see fit. From the ADF Data Control Palette, drag the AppModule.HrmFirstLevelView1 Collection to your page. In the UI Widget dialog, select ADF Tree. Subsequently, set up the tree binding rules in the following way: 

 Each tree level will have a rule. Select the Data Collection for the current level, select NodeLabel as Display Attribute and select the next (lower) level’s ViewObject as Branch Rule Accessor. Press the Add New Rule button to save this rule. Repeat this process for every level in the tree. For the lowest level there obviously is no Branch Rule Accessor to create – as this specifies the collection providing the child nodes which of course the lowest level does not have.

Now you can run the application. You should see our much coveted tree as displayed in the beginning of this article. Compliments to Jan R.!