DataProvider component for internationalizing Creator applications

The JavaServer Faces standard JSP tag library includes the loadBundle tag, which allows the developer to bind component values to keys in a Java properties resource bundle. While Java Studio Creator includes this tag on the component palette, there is a lack of good design-time support for binding to keys in the resource bundle, and bound values cannot be displayed at design-time. There have been a lot of complaints in the developer forum about this, and it is something that the Creator development team intends to address in an upcoming release.

In the meantime, I have put together a simple DataProvider component, PropertyResourceProvider, which plays the same role, but has much better design-time support.

How to install the PropertyResourceProvider

Download the PropertyResourceProvider complib to a local directory. From within Creator, open up Tools -> Component Library Manager, and click on "Import". Use the browse feature to locate the downloaded component library, and select it. The library contains a single component, PropertyResourceProvider, which you can import into its own category, or into a pre-existing category.

How to use the PropertyResourceProvider

A PropertyResourceProvider wraps a Java resource bundle file, and makes the keys in the bundle file appear as data fields. In general, you should use one PropertyResourceProvider per resource bundle file. The component has a single property, baseName, which should contain the qualified base name of the resource bundle file. The property editor for the baseName property will show a list of all resource bundles available in the current scope, so you can just choose one from the list. If you aren't familiar with Java resource bundles, there is an SDN technical article that provides a good overview.

The overhead involved in creating a PropertyResourceProvider is minimal, so it is probably easiest to add them to each page on which they are needed.

Localizable component values will need to be added to a resource bundle, instead of being set directly on the component. There are a number of ways of adding new keys to a resource bundle file. You can click on the file in the project view to edit it directly (look under the Source Packages node), or you open the file node and right click on a locale node to add key and value pairs, one by one.

To bind a component to a localizable value, right-click on the component and choose "Bind to Data". Select the appropriate PropertyResourceProvider, and the keys currently defined in the resource file will appear as fields. Select a field, and Creator will set the property's value to an expression that binds to the selected field. Close the binding window, and you will see the property value appear in the designer. PropertyResourceProvide is just like any other DataProvider, so you can also edit property values in the component's properites sheet, or by choosing the "Property Bindings..." context menu item.

The PropertyResourceProvider will automatically choose the correct bundle file to load based on the locale of the Faces context for each request. This locale is determined by examining the client locale of the incoming HTTP request, and the list of supported locales given in the application's faces-config file. Typically, adding a locale to a project involves two steps:

  • You add a locale-specific version of each bundle file. See the SDN technical article referenced above for more information about naming conventions for bundle files.
  • You add the locale to the list of supported locales, in our project's faces-config file. You will find this file in the Files window, under your application's web/WEB-INF directory. For an application that supports two locales, French and Spanish, in addition to the default locale of English, the relevant fragment of the faces-config file would look like this:
      <application>
        <locale-config>
          <default-locale>en</default-locale>
          <supported-locale>fr</supported-locale>
          <supported-locale>es</supported-locale>
        </locale-config>
      </application>
    

Hope this helps!

Comments:

Thanks for this great improvement! I got almost everything working - only one thing I could not manage: I am working on a little web application where the user can select the locale at runtime. The locale change works perfectly when not using the PropertyResourceProvider. However, with the PropertyResourceProvider in place, it doesn't change the property values to the new locale. Do you have a running example that demonstrates this behaviour? Thanks a lot, Matthias

Posted by Matthias Unverzagt on August 28, 2006 at 01:17 PM PDT #

I have a few sample applications, one of which demonstrates dynamically-select locales in action. This application is localized to French, and includes a drop-down list from which the user chooses a locale. If French is chosen, you will see the labels change to French. If Spanish or English is chosen, the labels change to English. You can download the the compressed application, un-Zip it, open it in Creator, deploy, and try it out.

Posted by Gregory Murphy on August 28, 2006 at 02:20 PM PDT #

Thanks for the example! The only difference to my application: The PropertyResourceProvider is in RequestScope (PageBean) in your example, I put it to SessionScope (SessionBean1). If I switch to RequestScope it works in my application too. What is the best practice that you suggest? How is ensured that the property files are read only once - within a session or within the application lifetime?

Posted by Matthias Unverzagt on August 29, 2006 at 02:33 PM PDT #

The problem is that as currently designed, the provider caches the resource bundle once it is first requested. If the provider is in page scope, the cache is cleared with each request, but if it is in session scope, it is never cleared. So, the provider only works for dynamic applications when placed in request scope.

This is a bug which I will fix for the next version. Thanks for pointing it out!

Posted by guest on August 31, 2006 at 02:17 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

gjmurphy

Search

Top Tags
Archives
« July 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today