Reset ExecuteWithParams - a different approach

This blog speaks about a quick and efficient way to clear a form based on a View-Criteria, which is exposed on the GUI as an ADF form field.

The setup is simple enough.

1. Create a ViewObject - EmployeesVO, based on the EMPLOYEES table of HR schema.
2. Create a ViewCriteria - EmployeeSearchCriteria, with criteria of your choice.
3. Shuttle the ViewCriteria onto the View Object's Application Module instance.
4. Drag and drop the ExecuteWithParams action on the GUI as an ADF form.
5. Add two buttons - Search and Reset.

Here's how it stands now:

And this is how the GUI looks:

The "Search" button calls the ExecuteWithParams action. Nothing exciting there.

But how do we reset the form? One crude way is to just get hold of each attribute binding, and setting them to NULL. But what if your View-Criteria has many attributes to search on? It becomes really tedious to individually set each attribute to null.

Here is where the ADF BC comes to our rescue.

The ViewCriteria class has a method - getAllBindVariables - which returns a collection of oracle.jbo.Variable objects. So just grab the ViewCriteria object from the ViewObjectImpl, and get a list of all the bind variables used in that criteria.

To utilize the power of this method, I wrote a helper method in my AMImpl class, which accepts the view-object instance name and the view-criteria name, and returns a list of all the bind variable names used for that criteria.

In my managed bean, the reset button's action-listener calls this client method and gets back this list. I loop over this list and then set each value as null.

The console prints all the bind variables which belong to view-criteria "EmployeesSearchCriteria", which is exactly how you had created the criteria.

So, when you search:

When you clear (by the way, I also added an executeEmptyRowset), all the input components are reset.

And that is all!

The sample application is built on JDeveloper and HR schema. The source code is available on Github.


  1. This is bad ADF design: Why would you need two custom BC methods, then one call to ADFUtils.setBoundAttributeValue() for?

    All you should have one custom method on AMImpl that executes the ENTIRE logic. Your ActionListener should have only a call towards the BC method, that;s all.

  2. I could not agree more Florin. In a real implementation that's how I'd do that. This break-up is just to demonstrate the various mini-modules into which the entire logic can be broken down.


Post a Comment