Vincent Massol wrote:
> Ok. Here is my use case :
>
> <configurationFactory>
>
> <bundle id="short name1"
> [language="language1"]
> [country="Country1"]>
>
> /path/to/bundle1
>
> </bundle>
>
> </configurationFactory>
>
> In the implementation code I'd like to take one action if no
> language/country are specified and another if they are (because behind
> the scenes I need to call an API which has 2 signatures, one with a
> Locale and one without - I don't want to get the default locale and only
> use the signature that accepts a locale as this would mean I override
> the default implementation of the API I'm referring to as I would
> introduce my own logic).
The single parameter method is only a shortcut for what you are really
doing. It is not your "own" logic per se.
In your case, the ResourceBundle.getBundle(String) method is exactly the
same as:
getBundle(baseName, Locale.getDefault(), this.getClass().getClassLoader())
As it says directly in the JavaDocs. The Locale is a bit different if
you are not using the default because you have to have a language, but
can further specify it with a country or variant.
In this particular case, I might do something like this:
Locale defLocale = Locale.getDefault();
String language = conf.getAttribute("language", defLocale.getLanguage());
String country = conf.getAttribute("country", defLocale.getCountry());
Locale usedLocale = new Locale(language, country);
getBundle(baseName, usedLocale);
Ideally, you would have a static constants interface that would define your
default language/country:
interface Constants
{
String DEFAULT_LANGUAGE = Locale.getDefault().getLanguage();
String DEFAULT_COUNTRY = Locale.getDefault().getCountry();
}
> I can imagine lots of cases where you would need to verify if an
> attribute exists because you may want to do something different if it
> does than if it does not.
We would have to vote on adding the "boolean attributeExists()" method
to Configuration. It might not happen, and I am +0 on it. I'm not
going to stand in it's way, but not totally convinced it's necessary.
> Ok about immutability :)
>
> Forget about hashtable. Isn't there an ImmutableHashtable in a utility
> class anywhere that would have the same API save for the write methods ?
java.util.Collections.unmodifiableMap(Map)
And for this purpose is a hack.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
