What if you missed the Key definition for a ViewObject ?

When you create ViewObject WITHOUT choosing EntityObject as data source, there are chances that you may forget to define Key for the generated ViewObject. Actually the Key definition play a very vital role when ADFm(binding layer) comes in to picture. Many of the binding specific APIs make use of the 'Key' from the ViewObject to identify rows uniquely. Let me share a couple of issues that may arise if you miss out Key definition for a ViewObject

1. RichTable::getRowData() returns null.

Please see the below shown code snippet. This code is typically used to get the data for the selected rows for a table from the backing bean.

RowKeySet selectedRowKeys = someTable.getSelectedRowKeys();
  
//Store original rowKey
Object oldRowKey = someTable.getRowKey();

if (selectedRowKeys != null) {
    Iterator iter = selectedRowKeys.iterator();
    if (iter != null && iter.hasNext()) {
    Object rowKey = iter.next();
    someTable.setRowKey(rowKey); //stamp row
    JUCtrlHierNodeBinding rowData =
        (JUCtrlHierNodeBinding)someTable.getRowData();
    //Do something here
  }
}
  
//Restore the original rowKey
someTable.setRowKey(oldRowKey);

If you don't have Key defined at ViewObject level, call to someTable.getRowData() may return null. In that case, solution is to revisit your ViewObject and define a Key :)

2. Hitting the "java.lang.IllegalStateException: ADFv: Not inside a container error" when a tree(tree table) node is expanded by the user.

java.lang.IllegalStateException: ADFv: Not inside a container.
        at oracle.adfinternal.view.faces.model.binding.FacesCtrlHierBinding$FacesModel.exitContainer(FacesCtrlHierBinding.java:673)
        at oracle.adfinternal.view.faces.model.FlattenedTreeCollectionModel.getRowIndex(FlattenedTreeCollectionModel.java:111)

As a first step to debug this error, please check the underlying ViewObject to ensure the Key definition for the same.

Disclaimer
Please note that there may be multiple reason for the above listed error(s). What I'm sharing in this post is just one among many reasons. Let this be a staring point while debugging issues with similar symptoms :-)