ADF Faces: Programmatically setting SetActionListener….WHY?

Question: Because the af:setActionListener component is intended to avoid some managed bean code, is there any particular reason why programming with SetActionListener should be preferred?

1) MORE CONTROL: it gives more control...e.g. we can have:

if(A) EL.set("#{sessionScope.someOtherAttribute}", EL.get("#{sessionScope.someAttribute}"));

else if (B) EL.set("#{sessionScope.someOtherAttribute}", EL.get("#{sessionScope.someAttribute2}"));

2) NO CASTING ISSUES: There are casting issues with af:SetActionListener when TO field is pointing to primitive data type e.g. boolean (small b)

if a variable (e,g, enbaleUpdate) is of type boolean rather Boolean then the following line throws EvaluationException ( IllegalArgumentException: type mismatch)

<af:setActionListener to="#{UserStateBean.enableUpdate}" from="true"/>

3) EASIER TO DEBUG: For case like (2) I have found it pretty hard to debug af:SetActionListener component (as compared to code in backing bean)

Hiding Details if Master doesn’t have any in ADF Faces Tables

I had a use case in which some rows in the Master Table can never have any details; so it makes sense to hide details table instead of printing a blank table with some default text message.

I tried to fit in lot of (buggy) logic and then I realized it can be done using simpler way which is:

Let say the child table has

value="#{bindings.ChildCollection.collectionModel}"

to hide details add:

rendered="#{bindings. ChildCollection.estimatedRowCount>0}"