Hi all,
I have a few questions and considerations regarding the Trinidad locale
data handling model. Please see below.
Your comments are greatly appreciated.
Thanks a lot
Kenneth
----------
With my understanding..
- In Java layer, Trinidad and ADF Faces are having leverage on JRE
locale support. They do not keep independent set of locale data.
- In Javascript layer, we are maintaining an independent set of locale
data under Trinidad. So far I found.
LocaleElements_*.js in trinidad-impl.jar
LocaleElements_*_ORACLE10G.class, LocaleElements_*_ORACLE10G.js in
adf-richclient-impl-11.jar...!?
Now, here are my questions...
1. How do we generate the locale data set for Javascript layer (i.e.
LocaleElements_*.js)?
As far as I understand, the architecture/implementation of converters
(DateTimeConverter, NumberConverter) assume that there is consistent
locale data between Java and Javascript tier. Likely there is a
script/build-tool to generate the data set out from JRE API. Can
someone please point me to it?
2. Following up Question #1, JRE locale definition sets are updated
every releases. i.e. they are different between JDK 1.4, 1.5, 1.6,
etc. Does it sound like we may run into issues here? For example, the
current locale data set seems to be generated based on 1.4. When
Trinidad/ADF Faces runs with 1.5, inconsistent data may get us into i18n
bugs. Any suggestions?
(I am trying to write up a testcase to validate this)
3. Provided that Trinidad will keep maintaining its own locale data set
in Javascript, should we update it and sync up with JDK1.5 (or even 1.6)?
4. Following up Question #1 again, how do we get all required locale
data from Java?
The public JRE localization API can give us most of the locale data we
need, but _NOT_ all. For instance, afaik, there is no public API we can
get date format patterns from Java.
e.g. Copying from LocaleElements_en.js....
DateTimePatterns:["h:mm:ss a z", "h:mm:ss a z", "h:mm:ss a", "h:mm a",
"EEEE, MMMM d, yyyy", "MMMM d, yyyy", "MMM d, yyyy", "M/d/yy", "{1} {0}"],
To get it, one way is make calls to Sun internal API's, for example,
sun.text.resources.LocaleData.
Maybe the pointer from question #1 can help answer this.
5. Are those "ORACLE10G" locale data still be used?
