Right getters for "Boolean" and "boolean" values

In this post I would like to highlight a small pitfall that sometimes spoils ADF/JSF developers lives.  It happens when an EL expression on a page is referring to a boolean property of a managed bean or an object and a getter for this property is declared in a wrong way. This leads to either PropertyNotFound or  PropertyNotReadable exceptions.

Let's consider a simple example. There is a managed bean with the following methods:

  public boolean isPrimitiveValue()
  {
    return true;
  }


  public Boolean isObjectValue()
  {
    return Boolean.TRUE;
  }

There is a page with a couple of buttons referring to the he managed bean:

 <af:button text="button 1" id="b1" rendered="#{theBean.primitiveValue}"/>
 <af:button text="button 2" id="b2" rendered="#{theBean.objectValue}"/>

It works well for the first button, but it doesn't for the second one raising a PropertyNotFound exception like "...The class 'com.cs.adfpractice.view.TheBean' does not have the property 'objectValue'...".

The thing is that the EL engine can't resolve a getter starting with "is" for the Boolean type returning an object. It works only for the primitive boolean type.

If we change the second getter like this:

  public Boolean getObjectValue()
  {
    return Boolean.TRUE;
  }

It will work perfect.

That's it!

Using Custom View Objects with Entity Associations

While implementing business logic at ADF BC layer we leverage entity associations in our code as a convenient approach to manipulate entities that are related to each other by design. For example, there is DepartmentEmployeesEL association linking Department and Employee entities. In Department entity implementation class there is an association accessor returning a row iterator with employees working for this department:

  public RowIterator getEmployees()
  {
    return (RowIterator) getAttributeInternal(EMPLOYEES);
  }

This accessor can be used in a method iterating over all associated employees and performing some actions with each of them:

  private void processEmployees()
  {
    RowIterator employees = getEmployees();
    while (employees.hasNext())
    {
      EmployeeImpl employee = (EmployeeImpl) employees.next();
      // do something with employee
    }
  }

In order to retrieve the list of employees the framework builds an internal view object according to the association definition. However, there is a way to control how this view object is going to be created, for example we want to specify a desired sorting order or add an extra where clause to the VO query. We can tell the framework to use our custom view object definition instead of using a default one:

Having done that we have a full control on how the rows returning by the association accessor are going to be retrieved from the database.

That's it!