ADF 11g: Passing Information to Bind Variables

For the past year, I’ve been working with a customer on a large Oracle BPM project.  As part of the project there are a couple forms written using Oracle’s Application Development Framework (ADF.) I’d like to do a small series on this blog of useful techniques that have helped me with a successful implementation in a large scale production environment. Today, we’ll be talking about how to pass information from the ADF binding layer to a named parameter that is setup on a view object in the model layer.  This comes up pretty often and there are some neat things you can do using the technique.

Let’s take a look at our view object first.

The query for the GetEmployeesInDepartment view object.

For this discussion we are using the HR sample schema that comes with an Oracle database. As you can see this view object uses a query that has a single bind variable that represents a department id. Its result set will be all the employees which belong to the supplied department. Our use case is going to be a table that will display employee information based on the department selected in a drop down list. There are many ways to do this type of thing in ADF and this isn’t necessarily the best use case for it but it has the advantage of being simple to follow and explain. We will talk a bit about some other uses for this technique later on.

To make this work we need something that will give us a department ID to pass to our view object. I have created a very simple view object called DepartmentList which just returns all departments. This result set includes the department name as well as the department ID. In our ADF bindings I have created a list binding to this view object with the department name selected as the display attribute.

Our list binding to the DepartmentsList view object.

I have also created an attribute binding to the DepartmentId attribute that’s bound to the same iterator as the list binding.

You can see that DepartmentsList and DepartmentId are both linked to DepartmentsListIterator.

Now when the Iterator get’s updated, by say, a drop down list selection, this DepartmentId attribute binding will have a valid department id as its inputvalue. Neat! We just need to pass this to our view object and we’re done. You may have noticed a tree-binding in the above picture called GetEmployeesInDepartment. This is the binding we will use for our employee table display in the view layer. It is bound directly to the GetEmployeesInDepartmentIterator which will be populated with the result set from our view object once we give it the department ID that we have stored.

The last remaining thing is how do we execute the view object with our department ID? The secret sauce lies in our action binding.

You can see we binding to the ExecuteWithParams operation off the Iterator.

Since the view object has a named parameter the ADF framework gives it an operation called ExecuteWithParams automatically. All we have to do is make a binding to this ExecuteWithParams action and pass in our DepartmentId as shown. The final piece of the puzzle is how does this action binding actually get executed anyway? To do that I have added an invokeAction executable called RefreshEmployeesTable.

You can see how we bind to LookupEmployees.

Because we have told it to refresh during the ‘renderModel’ stage it will execute before any of our UI is rendered and pass the value of DepartmentId to our GetEmployeesInDepartment view object. And since the table is bound to that view object via the iterator that’s what it will display!

A quick and dirty UI.

So all the pieces are in place, now we just create a dropdown list and make sure it is bound to our DepartmentList binding, we create our table bound to GetEmployeesInDepartment, and all we have to do now is put a PartialTrigger on the table that points to the dropdown. This will make the table refresh itself for us when the dropdown is changed.

Ta da!

And it works as expected. One of the nice things about this is that we didn’t have to write any code to implement this functionality.  One of the other ways of using this, and one I use quite a bit, is when you have the requirement for a dropdown list to contain a subset of some result set that changes depending on who is looking at it.  For example, an Accounts Payable user could possibly have more valid selections in a drop down list than a General User.  By utilizing ADF Security and passing in the type of user that is currently looking at the page you can display filtered results from the same view object and same UI component.  This is a pretty powerful technique that I use often.  I’ll revisit it when I do a post on ADF Security itself to show it off a bit.