How to get keys on multilevel tree?

Question

Hello,
I've got a problem with a multilevel tree with 3 levels on 3 related tables: grandparent -> parent -> child.
When the user selects a child node (a leaf of the tree), my selectionListener needs the 3 primary keys: 1. for the current grandparent row on the path of the node, 2. for the current parent row on the path of the node, 3. for the child node the user has just selected.
However, getSelectedRowKeys() is returning just the grandparent key, not a set with the 3 keys leading to the leaf node.
My tree is defined as
       <af:tree value="#{bindings.GrandParent.treeModel}" var="node"
                selectionListener="#{backingBeanScope.untitled1.treeSelectionListener}"
                selectedRowKeys="#{bindings.GrandParent.treeModel.selectedRow}"
                rowSelection="single" id="treePTM"
                binding="#{backingBeanScope.untitled1.treePTM}">and my listener is
  public void treeSelectionListener(SelectionEvent event) {
    ELUtils.invokeMethod("#{bindings.GrandParent.treeModel.makeCurrent}", SelectionEvent.class, event);
    RowKeySet rks = ((RichTree)event.getSource()).getSelectedRowKeys();
    Iterator i = rks.iterator();
    while(i.hasNext()) {
       Object rowKey = i.next();
  }the single rowKey object returned only has the grandparent key, not the triplet (grandparent key, parent key, child key).
How to get all the primary keys leading to the currently selected node when the selected node is not at first level?

Answer 1

Hi,
no, that code is fine.
I solved by removing this property from the tree definition:
selectedRowKeys="#{bindings.GrandParent.treeModel.selectedRow}"
then rowKey has 3 values instead of 1.
I use to set selectedRowKeys that way because that mimics what JDev declares automatically for af:table and that also automatically selects the first element in the tree (I'll just try to manually select the first element form code to workaround this)
I thought treeModel.selectedRow held a reference to all the primary keys but this turns out not to be true. Thanks anyway for looking into this.