Automatically Applying Get Posted Attribute Method for Row Refresh

There is out of the box ADF BC method available to refresh current row, see this post for details - Refreshing Single Row Without Full Rollback. There could be use cases, when refresh method is not sufficient (particularly for a row with dependent LOV's) - it may not reset data correctly. Also there is extra SQL query sent to DB, to fetch row data by key. Even it works well most of the time, still it is good to know the alternative. I'm going to present alternative row refresh approach here, using getPostedAttribute method.

User could edit data in the current row:

Press Refresh button:

All attributes are refreshed and synchronised back to the original values, currently available in the database:

UI data is synchronised with the help of Change Event Policy = PPR functionality enabled for iterator in the bindings, we can see synchronisation events executed in the log:

You should know - ADF BC method getPostedAttribute is protected, this is why we need to have a wrapper method in EO Impl, with public access. Wrapper method allows to invoke originally protected method from different class, other than EO Impl:

They key logic resides in refreshCurrentRow custom method, implemented in VO Impl class. This method gets a full list of EO attributes and for all attributes with index higher or equal to 0 (there could be accessors with negative index), it goes and retrieves posted attribute value. Current value is reset back with posted value - this is how attribute value is reset back to the same as it is posted to DB. Sample application is set to use DB pooling, this means it will always return actual value committed to DB, and it will ignore any temporary posted values (each request will get different DB connection):

Row refresh method is exposed to be accessible from the bindings layer:

As it was mentioned above, iterator in the bindings is set to use Change Event Policy = PPR, this is synchronising data displayed on UI with changes in ADF BC automatically:

Keep in mind, no matter if using standard row refresh method or approach described in this post - transaction still will remain dirty, only data will be reset. To clear transaction and revert it back to non dirty, user still must use full Rollback operation.

Download sample application - CustomRowRefreshApp.zip.

ADF Fragment Data Reload with Poll Component

If you are looking for simple but effective solution to refresh data in ADF, you might be interested to check ADF Poll component. This component integrates well with ADF fragments - reload event is isolated in the scope of fragment and not distributed to entire page, means whole page will not be refreshed, but only fragment. I will demo this below with example.

Sample application with ADF Poll component configured to refresh Employees table only - ADFPollFragmentApp.zip.

Employees fragment implements ADF table and Poll components:

Poll is set to initiate reload event every 5 seconds by default. It will stop sending reload events after 600000 seconds. PollListener is defined to implement reload logic:

PollListener re-executes VO SQL for the table and at the end sends Partial Trigger event to perform visual refresh for the Panel Collection UI component containing table with Employees data:

VO is re-executed by accessing iterator bindings from Page Definition:

Main page includes ADF region where Poll component is configured and additionally it contains another table component. There is one more table included to prove that data reload event is not distributed outside of the fragment:

We can see how it works. Open Departments tab from the main page, where no Poll component is configured and select any row from the table - remember your selection, we are going to check it later:

Go to the Employees tab and there check current salary value for Lex De Haan employee. Salary value is 17007:

Open database table and change salary value for the same employee to be 1500, commit your changes:

Switch back to page and you will see that during next data reload Poll event - change will be fetched to the UI:

Similar if you create new record and commit it in the database:

This record will appear in the UI automatically for you:

If you go to Departments, previously selected row still remains correct - this means Poll component was distributing reload event only in the scope of the fragment:

Refreshing Single Row Without Full Rollback

With ADF Rollback operation - ADF is reloading entire dataset from DB. It invokes ROLLBACK from database and then executes View Object to return latest data from DB for all rows. This works well when we want to undo multiple changes at once. It may happen to encounter such use case, where we need to undo changes per row, not per set of rows. This is possible in ADF as well - using refresh(...) method for ADF BC Row. But keep in mind, while this method refreshes selected row - it never cleans up ADF BC transaction, it will remain dirty. This is logical - ADF BC doesn't know, if there are other changed rows. This means - you should provide to the user both buttons:

1. Undo - will rollback changes for all rows and mark transaction clean (standard Rollback operation)
2. Undo Row - will refresh only selected row and keep transaction dirty (Described in this post)

In this post I will describe how to refresh selected row, download sample application - RowHighlight_v2.zip. This application is extended version of my previous sample from this post - Changed Row Highlighting in Oracle ADF Table.

We will see first, how ADF BC performs when executing standard Rollback operation. There are three rows changed, row selection is on last row:

Press Undo to invoke Rollback operation, when operation is completed - changes are cleared from all rows as expected, but there is side effect - row selection is lost and reset to point to the first row:

If we check in the log, there is plain SQL statement executed for entire data collection - without bind variable restriction, this re-executes View Object:

Will demo now, how single row refresh works. User needs to select row, where changes should be cleared:

Press Undo Row button - changes for the selected row will be cleared, without affecting existing changes for other rows. Its very important - row selection will stay on the same row as it was before invoking Undo Row operation:

Now we can see different picture in the log - ADF BC executes SQL restricted by bind variable and fetches only data for specific row we are refreshing. This will perform much better comparing to standard Rollback operation:

Single row refresh is implemented as custom method inside View Object implementation class. For current row we are calling refresh operation with REFRESH_UNDO_CHANGES and REFRESH_WITH_DB_FORGET_CHANGES arguments - this will force to reload current row cache:

This method is exposed through View Object client interface and is accesible from Data Control:

Method is declared in Page Definition:

Is invoked from Managed Bean action method: