You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Michael Concini <mc...@gmail.com> on 2009/09/15 18:42:18 UTC

question on standard-faces-config.xml and locale support

Hi,

I've discovered a problem which can occur in the way that we handle the 
default locales.  As thing are implemented currently, we populate our 
supported locales based on the list provided in the 
standard-faces-config.xml, plus any additional locales specified in the 
application's config files.  This can cause problems when doing things 
like currency validation in cases where a default-locale has not been 
specified in the app.

For example, suppose you are using f:convertNumber with type set to 
"currency".  When NumberConverter.getNumberFormat() is called, it will 
attempt to get the locale from the view.  The view however, in cases 
where there is no default specified, follows the JSTL convention of 
giving preference to the first language match instead of looking for an 
exact match among the supported languages. 

So, if you are expecting 'en_US' or 'en_GB', 'en' from the 
standard-faces-config.xml will return a match, but the number formatter 
associated with 'en' has junk for matching currency and validation will 
fail.  It seems to me that in cases where the application itself hasn't 
specified a locale, we should fall through to calling 
Locale.getDefault().  From a little experimenting, this appears to be 
how the RI works as it does not exhibit the same issue, although I am 
unable to look at the code to verify what its doing under the covers the 
runtime works as would be expected.

Anyway, a very simple solution would be to simply remove the 
<locale-config> section from standard-faces-config.xml.  As far as I can 
tell, it actually doesn't seem necessary in the first place and would 
then leave it up to the application to specify which locales to support, 
which seems to me would be the proper behavior.  Does anyone with more 
experience in this area have a different take on this?  Is there 
something I'm missing here.  

Thanks,
Mike