ADF Tutorial: How to executeWithParams with a LOV – SelectOneChoice and no command button

When creating and experimenting ADF Applications, a common thought or requirement would be to filter a table upon a selection from a LOV. This might sound straightforward to implement; Autosubmit to the LOV, ExecuteWithParams in the ValueChangeListener, partialTrigger on the table and buya, this should be enough. Later on you would find out that the behaviour is not the expected. 

For this requirement, we want to filter an employee table by department. We don’t want to press a button after we have selected the department from a LOV. We have applied a View Criteria to the Employees View Object to be filtered by departments. So let’s see;

We have configured the ExecuteWithParams parameter (departmentId) to be displayed as a SelectOneChoice component and we have selected AutoSubmit => True and ValueChangeListener => #{bindings.ExecuteWithParams.execute}


So what happens at runtime? When we first run the application we should get all employees and no value for the exeuteWithParams parameter.


Since the selectOneChoice has AutoSubmit and a valueChangeListener to executeWithParams and the table a PartialTrigger to the selectOneChoice component, if we update it, table should be refreshed. Let’s see;


It seems the table was refreshed but we can still see all the employees. Let’s try a different department;


This time the table refreshed but its showing us employees from the previous department selection! If we update the department again, then we should see employees in Sales;


The problem has to be with our approach and the ADF Life Cycle. The valueChangeListener gets executed in the validation phase and the model is updated just after this. Knowing this, when we select IT department, the executeWithParams is executed with its parameter still null. After this, the model is updated and the parameter is set to IT. Now, when we select Sales department, the executeWithParams is executed with its parameter being IT and after, it gets updated to Sales.

To tackle this problem, we need to update the model before the executeWithParams is executed. We can achieve this by writing a custom valueChangeListener where we first update the parameter, then call executeWithParams and later on refresh the table adding a partial target;

We update the parameter by referencing the bindings through EL. The only issue with this approach is that you create a dependency of you Java Code and your Bindings names; in this case, if “inDepartmentId” changes its name, then this code will fail. Then, we execute the operation bindings and last thing is to add a partial target to the table.


After this is in place, when we run the application, the selection works as we wanted;


Update: The following use case can be easier implemented by using a Navigation List in the Departments VO. Employees should be dependent of department through a View Link. This approach doesn’t require any code. Thanks to Frank Nimphius for the update.

Leave a comment

Your email address will not be published.

Social Media

Stay up-to-date with our latest ADF and related technical posts via your favourite social network services.