ADF: Unexpected validation, ChangeEventPolicy and immediate editable table

When using ADF editable table, you could come across annoying unexpected validation error messages. For example, when you CreateInsert a new row with some mandatory attributes in an editable table, without proper control, your could get validation error messages even before you type anything in the newly created row. It gets even worse when you try to change the current selection of rows, you will get more repeated validation error messages.

You can control this kind of strange behaviors of ADF editable table by setting the ChangeEventPolicy attribute of the iterator binding to none, and the immediate attribute of the table component to false.

Change Event Policy

You can find more information about the ChangeEventPolicy attribute from the section 27.2.1 What You May Need to Know About Partial Page Rendering and Iterator Bindings of the documentation Developing Fusion Web Applications with Oracle Application Development Framework at:

http://docs.oracle.com/middleware/1212/adf/ADFFD/adf_lifecycle.htm#ADFFD22893

In the CreateInsert case, with the default value ppr set for the ChangeEventPolicy attribute of the iterator binding, when you try to create a new row by clicking the button bound to the CreateInsert operation, A POST request is sent to the server and a new row is inserted in the data model. The response for that request will instruct an automatic PPR request to be posted right after the CreateInsert request, even before ADF updates the table and render the UI components for the new row. It's this subsequent request causes the validation, which is too early.

When you disable the automatic PPR request by setting the ChangeEventPolicy attribute of the iterator binding to none (and setting the partialTriggers of the table component to the CreateInsert button, so that the button event will trigger the rendering of the table), the button and table will behave properly: a single request is posted when the button is clicked; a new row is inserted; the table component is updated with the UI components required for the new row, and these updates are sent back within the response and partially rendered in the page. 

Immediate Table Component

With a table component that supports selection, when the current selection changes, a selection event will be sent back to the server with a POST request. It's no surprise that all form fields in the table, are posted back together. It's this request that triggers the validation, in case the immediate attribute of the table component is set to the default value false. 

By setting the immediate attribute of the table component to true, validations of other components which are not immediate will be bypassed. In this way, we get rid of the unexpected validation, and leave it to later process, when the transaction is about to complete.