ADF best practices – get/setAttribute

I have always seen code like this (using getAttribute and setAttribute) in various ADF applications. It seems perfectly alright, but I see few issues with this approach and in my opinion this should be avoided.

• First, this takes more time to code than type safe approach shown later in this blog entry.
• Issues not captured during compile
  • we are intending to use some Employee view object here, but there is no type check. ViewObjectImpl is base class for all view objects.
  • we are coding name of attribute, in this case “IsActive”, but developer may have typed that incorrectly, or worse it may change in future.
  • we are assuming that it returns String, but that can only be proven when this code executes.
  • if you change data type of this attribute, you will not know till this code fails with ClassCastException at runtime. 
• IDE generally provides way to find usages for method, but in this case, we can not easily find out usage for specific attribute.

ViewObjectImpl vo = getEmployeeDisplayVO();
Row currentRow = vo.getCurrentRow();
String activeValue = (String) currentRow.getAttribute("IsActive");

Here is type safe approach. This requires that you generate Java files, which i always do by setting JDeveloper Preferences. We can argue that generating java code is unnecessary, but you may have to do that anyway in case of custom entity validation or client interface methods. It seems better to just have Java files always generated and utilize type safe coding approach.

EmployeeDefaultVOImpl employeeVO = getEmployeeDisplayVO();
EmployeeDefaultVORowImpl currentRow = (EmployeeDefaultVORowImpl) employeeVO.getCurrentRow();
String activeValue = currentRow.getIsActive();

With this approach, you can use IDE features to auto complete your code and you don’t have to worry about remembering names or type of attributes.