October 18, 2010

Why using RowSet Iterator Instead of Iterator Binding from UI?

When ever you are working with View Object Instances and your use case demands for iterating thru the rows using programmatic iteration,The recommended way for this is to create a second rowset iterator and not to use the one which is bound to the UI.

Code Snippet Illustrating the same

public void doSomething() {
    ViewObject vo = getViewObject1();
    RowSetIterator iter = vo.createRowSetIterator(null);
   
        while(iter.hasNext()) {
            Row row = iter.next();
            //your custom code
        }
    }

WHY???

Cause:

    1. The iterator bindings determine what row the end-user sees as the current row in the row set. If your own programmatic logic iterates through the row set using the same default row set iterator that the iterator binding uses, you may inadvertently change the current row the user has selected, leaving the user confused.

     2. Iterator bindings force their row set iterator to be on a valid row to guarantee that UI components display data when the row set is not empty. This has the side-effect of preventing your custom logic from navigating to the slot either before the first row or to the slot after the last row (when it is using the same row set iterator as an iterator binding). In concrete terms, this means that a typical while (rowset.hasNext()) iteration loop will either be skipped or start by processing the second row instead of the first

No comments: