The default value of the "selectionListener" attribute for an af:table component normally looks like this:
selectionListener="#{bindings.IterBinding.collectionModel.makeCurrent}"
But if some special selection processing is required, one can specify custom handler for the selection event, usually in a backing bean. As a first step in this custom handler, the default functionality for making the row current is invoked programmatically. This may look like the following code snippet:
public void testSelectionListener(SelectionEvent selectionEvent) {
JSFUtils.resolveMethodExpression("#{bindings.IterBinding.collectionModel.makeCurrent}", null,
new Class[]{SelectionEvent.class}, new Object[]{selectionEvent});
}
This should behave exactly like the standard selection handler, right ?
But it doesn't.
When triggering the selection change by clicking on a check box in one of the table columns, the "valueChangeListener" for this af:selectBooleanCheckbox does not fire on this occasion. It fires when clicked a second time. When using the default "selectionListener" it fires always as expected.
Any ideas what's wrong with the custom handler ?
Ok, the culprit for this strange behavior has been found.
While editing the page markup, JDeveloper changed the value of the "ChangeEventPolicy" attribute on the iterator binding in the pageDef file from "default (none)" to "ppr".
This leads to this strange behavior.
After manually reverting to the original value, everything works as expected.
The "ppr" setting seems to be pretty buggy, I already had similar problem with an af:panelTabbed, where I got a mysterious error message when switching between tabs from time to time.