You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mattias J <mj...@expertsystem.se> on 2005/05/09 21:46:02 UTC

[i18n] Continued development

Daniel, I see you checked in my refactorings now. Thanks.

To solve one of the issues previously discussed - with one provider 
throwing an exception and another one returning null for a particular case 
- I have the following idea:
Let's extend the MessageProvider interface to include both getText() - 
which throws an exception if not found - and findText() - which returns 
null if not found. (Something like the difference between Hibernates 
Session.load() and .find()).
Then for the MessageProvider implementations, you will only actually 
implement one of these - which should be clear by the documentation. Either 
you implement findText() and have getText() throw an exception if the call 
to findText() returns null, OR you implement getText() and have findText() 
return null if the call to getText() throws and exception.

This way we will not only solve the inconsequence problems; we will also 
increase performance by using findText() in MessageManager and thus 
avoiding throwing and catching exceptions while looping (assuming the 
MessageProvider implements findText() that does not throw, that is).

Therefore, if we only want findText() OR getText(), I would suggest findText().


As to the other issue, that ResouceBundles returns the entry of the default 
locale if not found for the specific locale while XML does not, I assume 
the most straight forward would be to have XML behave the same way 
ResourceBundles does. AFAIK there is no way to change the behaivor of 
java.util.ResourceBundle and providing our own implementation would not 
only cost a lot of time, but feel just "wrong".

(B.t.w. I have started working on naming/qualifying provider and will post 
a diff when I'm done)

   /Mattias J


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org