From the user side of view rollback is expected to return to him to the same state he was when he last saved data.
So when the user that work on a Form (Row) presses Rollback and looses the row that he was working on is really confusing for him.
Fortunately Steve Muench has issued a workaround for this that many people use now in ADF applications.
http://blogs.oracle.com/smuenchadf/examples/
68. Restore Current Row After Rollback
Yet the above workaround does not work when View criteria are applied in view object and latest changes committed does not comply with these criteria.
This happens because Rollback forces query to re-execute with the applied view criteria and the changed (current) row does not exist in the new results set.
So for example in the current application there is a query and an edit page.
If you Query departments for specific manager (i.e. 100) and go to edit page if you change manager (i.e. to 200) and commit, after that if you press rollback you will loose that row since there is no longer in the queried rows.
I have applied a workaround in the current test case for that issue. In the beforeRollback of the view object I add a View criteria row that matches the current row primary key. This causes the current row always to comply to view criteria when we press rollback since in the query it is added
WHERE …. or (PK_FIELD = CURRENT_ROW_KEY)
In method afterRollback I remove the specific criteria row so that if the user query again (not by rollback) the results without the current row to be fetched.
This way the current row is not lost when it does not comply with applied criteria and we press rollback.
This workaround we have implemented in our Base ViewObjectImpl class and works also with composite primary keys.
The only issue is that with applied view criteria with no values the ‘or’ operator does not apply and only the current row remains in the result set after the rollback.
Test Case:
http://adfbugs.googlecode.com/files/TestRollbackToSameRowVC.zip
No comments:
Post a Comment