Technical Articles relating to Oracle Development Tools and Frameworks

  • ADF
    October 15, 2014

Using a Translatable String as the Default Value for a Bind Variable

Duncan Mills

I've just been looking at a scenario where we needed to populate an ADFBC query bind variable using a predefined value. Now that in itself is not difficult - the bind variable definition takes a default value exactly for this, however, in this case the value supplied as the default needed to be read from the locale specific resource bundle.

I wondered here if it would be possible to convert the default value for the bind to be an expression rather than a literal and use groovy to derive the translated string?

Well it took a little bit of time to come up with the correct path, but indeed it turns out to be possible with one small constraint about the keys in the bundle that have to be used.

So to start off, here's the groovy expression I use in the default value for the bind variable: 


That expression refers to a translatable property called TRANSLATABLE_BINDVAR defined in the relevant View Object as a custom property (General finger tab, Custom Properties section). this, in turn, maps to a resource in the bundle with a key generated from the full name of the View Object + property name + "_VALUE". e.g. in this case:


This is the resource that you can then translate and the value of which will be used at runtime.

An Explanation

 So what does this all mean? Unfortunately there is no way (that I've found) in groovy to reach directly into the ui hints of the bind variable itself If you start the expression with adf.object to start from the variable itself you can't really get anywhere.  So instead, we have to walk up the component hierarchy to the View Object that owns the bind variable and then get the resource from there. Just asking for the value of the custom TRANSLATABLE_BINDVAR property.  By using a translatable custom property for this, the developer has an existing UI to use that will create the resource keys for them. Furthermore, because we use the getProperty() API on the View Object  as an indirect way of getting the value, rather than using ResourceBundle APIs, we don't have to worry about finding out what locale to use - that's all handled automatically.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.