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

Passing Values to ViewObject Binding Parameters

Using Named Bind Parameters with ViewObjects

In order to avoid any SQL injection attacks , named bind variables or positional parameters approach is recommended wherever you set ViewObject where clause.

Here is the code snippet for the bind parameter approach:

public void addWhereClauseWithNamedBindParams(){
        ViewObject vo=this.getEmployee();
     
        vo.setWhereClause(null);
      
        vo.setWhereClause("Empno=:eNo");
        vo.defineNamedWhereClauseParam("eNo",new Integer("123"),null);
        vo.executeQuery();
      
        vo.removeNamedWhereClauseParam("eNo");
        vo.setWhereClause(null);
    }


Using Positional Parameters

Here is the code snippet for positional parameters approach:

public void addWhereClause(){
        ViewObject vo=this.getEmployee();
      
        vo.setWhereClauseParams(null);
        vo.setWhereClause(null);
      
        vo.setWhereClause("Eno=:1");

        vo.setWhereClauseParams(new Object[]{new Integer("123")});
      
        vo.executeQuery();
      
        vo.setWhereClauseParams(null);
        vo.setWhereClause(null);
    }

Mac: Kill Dashboard

Many users have abandoned OS X’s dashboard functionality either completely or in favor of alternatives like GeekTool. If you never want to see your dashboard again, you can kill it completely with the following Terminal command.

defaults write com.apple.dashboard mcx-disabled -boolean YES

To bring it back, change the “YES” to “NO”.