ADF BC and Faces: Fun with Bind Parameters Part Two – Locale specific database querying from the ViewObjects

Lucas Jellema
0 0
Read Time:6 Minute, 24 Second

In this article I would like to demonstrate another unexpected usage of ADF BC bind-parameters. In a previous entry I argued that bind parameters are typically seen as good only for the where-clause of an SQL query underlying a ViewObject. In that entry I showed using a bind parameter to select between very distinct order by clauses. Now we will take a look at using a bind parameter to select the meaning associated with domain values in the proper language, as defined through the UI locale. The article as an aside demonstrates how we can change the locale on the fly, by selecting the desired value from a set of radiobuttons. Note: that part of the discussion is based on one of the undocumented samples from Steve Muench.



The table that holds our domains of allowable values:

create table domains
( name varchar2(40)
, value varchar2(100)
, meaning_en varchar2(500)
, meaning_nl varchar2(500)
, meaning_de varchar2(500)
, meaning_fr varchar2(500)
, meaning_it varchar2(500)
, meaning_es varchar2(500)

Each supported language has its own language column. Of course we could have opted for a more normalized design, which would have had our table columns as name, value, locale, meaning. But we did not.

Entries in this table look like:

insert into domains
( name, value, meaning_en
, meaning_nl, meaning_de, meaning_fr
, meaning_it, meaning_es
( 'JOB', 'SALESMAN', 'Commercially active employee'
, 'Commerciële collega', 'Verkäufer' ,'Vendeur'
, 'Commesso', 'Vendedor'

insert into domains
( name, value, meaning_en
, meaning_nl, meaning_de, meaning_fr
, meaning_it, meaning_es
( 'JOB', 'MANAGER', 'The Boss'
, 'Leidinggevende', 'Chef' ,'Directeur'
, 'Responsabile', 'Encargado'

Depending on the desired UI language, we should select the appropriate meaning-column.


ADF Business Components – The Model project

We can create a ViewObject JobsView that we can use for querying the Job domain, for example for populating Dropdownlists in User Interfaces where users can set the value for items based on this domain. The query for this read-only view object can be defined like this:

select value
, case :locale
when 'en'
then meaning_en
when 'nl'
then meaning_nl
when 'it'
then meaning_it
when 'es'
then meaning_es
when 'de'
then meaning_de
when 'fr'
then meaning_fr
end meaning
from domains
where name ='JOB'
and nvl(:locale ,'XX') <> 'YY'

The key thing to notice for the purpose of this article is the use of the bind parameter :locale to determine which value should be returned as the meaning.


Our Model also contains an EmpView ViewObject based on the EMP table in the SCOTT schema. 

Developing the User Interface

Having the ViewObject all set up is a good thing. However, we also need the User Interface to demonstrate how we can leverage this View Object. I make use of JHeadstart to generate a simple page that shows a table with all employees in my EMP table, with a Dropdown (SelectOneChoice) for the Job item. JHeadstart will also generate a  dropdownlist for selecting the current language, so we can easily toggle between locales. Note: we need more than just a dropdownlist with languages in order to toggle between languages. The code behind this is taken from a sample by Steve Muench (see list of Resources).


1. Create a New ViewController project and JHeadstart-enable it using the JHeadstart wizard/plugin.

2. Create a New Application Definition File

3. Create a new dynamic domain Jobs, based on the JobsView. Set the Query Bind Parameters property for the Domain to locale=#{App.language}. This takes care of applying the value of the currently selected locale language to the bind parameter :locale in the JobsView.

4. Create a New Group, based on the EmpView, with Table Layout.

5. Associate the Job item with the Jobs domain; change the display type for Job to dropdownlist.

6. Create a Static Domain Locales, with the supported locales as allowable values  

7. Create an extra, unbound Item, called Locale. Set the display type to radio-vertical, set the domain to Locales; set Display in Table Layout to false and Display in Table Overflow to true.


The value of this item linked to the App backing bean’s language property, through an EL expression #{App.language}.

8. Set the property Depends on Item for the Job item (or any other item) to Locale.

Post generation changes:

Set the partialTriggers attribute for the generated table element – to have the table refreshed in a PPR operation when the Locale-selection is changed.


Configure the managed bean App in the faces-config.xml file:


The App class is a very simple bean:

package nl.amis.view;

import java.util.Locale;

public class App {
public App() {
Locale preferredLocale= new Locale("en");
String language = "en";
public void setPreferredLocale(Locale preferredLocale) {
this.preferredLocale = preferredLocale;

public Locale getPreferredLocale() {
return preferredLocale;

public void setLanguage(String language) {
this.language = language;
setPreferredLocale(new Locale(language));

public String getLanguage() {
return language;

Configure the supported locales in the faces-config.xml file – also configure a custom view-handler, that will set the locale on the ViewRoot, based on the setting in the App bean:


This custom ViewHandler class is developed by Steve Muench. My slightly modified class looks like this:


import oracle.adfinternal .view.faces.application.ViewHandlerImpl;

import java.util.Locale;

import javax.faces.FacesException;
import javax.faces.application.ViewHandler;
import javax.faces.component.UIViewRoot;
import javax.faces.context.FacesContext;
import javax.faces.el.ValueBinding;

* This custom view handler sets the preferred locale on the view root
* if it's different from the current locale, based on the preferredLocale
* property of the session-scoped managed bean named "App".
public class PreferredLanguageSettingViewHandler extends ViewHandlerImpl {
public PreferredLanguageSettingViewHandler(ViewHandler delegate) {

public void renderView(FacesContext facesContext, UIViewRoot uIViewRoot)
throws IOException, FacesException {
App app = (App) getEl("#{App}");
Locale preferredLocale = app.getPreferredLocale();

if (preferredLocale == null) {
} else {
if (preferredLocale != uIViewRoot.getLocale()) {

super.renderView(facesContext, uIViewRoot);

public static Object getEl(String expr) {
FacesContext fc = FacesContext.getCurrentInstance();
ValueBinding vb = fc.getApplication().createValueBinding(expr);

return vb.getValue(fc);

When we run the application, we see a table with Employees. The Job column is of displaytype dropdownlist. It shows all allowable values for Job in the currently selected language. When we change the Locale, the table is refreshed and we see the Job domain values for the new language. Notice that the Details button and Next link also change to the proper language.

In Dutch:

And in German:


Steve Muench’s Not Yet Documented Sample: Change Preferred UI Locale with a Button in the Page []

Download the JDeveloper Application demonstrated above:

About Post Author

Lucas Jellema

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director and Oracle Developer Champion. Solution architect and developer on diverse areas including SQL, JavaScript, Kubernetes & Docker, Machine Learning, Java, SOA and microservices, events in various shapes and forms and many other things. Author of the Oracle Press book Oracle SOA Suite 12c Handbook. Frequent presenter on user groups and community events and conferences such as JavaOne, Oracle Code, CodeOne, NLJUG JFall and Oracle OpenWorld.
0 %
0 %
0 %
0 %
0 %
0 %
Next Post

Fun with ADF BC Bind Parameters - Part Three: Support for generic bind-parameters in ADF Business Components

It can easily be the case that in your ADF BC application many ViewObjects make use of the same bind-parameters, for example a bind parameter referring to the current user. One simple way of providing the correct value for such bind-parameters could be implementing a little piece of pre-query-trigger-like logic: […]
%d bloggers like this: