geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B.J. Reed" <>
Subject Re: using Resource Bundles for message strings
Date Wed, 05 Mar 2008 15:22:54 GMT
ok. We'll use simple phrases as keys for the properties strings.

I haven't been clear about what the numbering scheme is for.  My concern 
isn't for collisions in the code, it's really for collisions and ease of 
finding info when a user asks "I'm getting message xxx, what do I need 
to do about it?".  My thinking is that it is easier to reference an 
error code rather than a whole message.  If there is some numbering 
scheme, that would help us in answering that question or we could use 
that numbering scheme on the web for easy user searches.  I'm thinking 
that the numbering should only be in the .properties files....or am I 
trying to solve a problem that hasn't been a problem - maybe we don't 
need a numbering scheme at all?

-- B.J.

Alan D. Cabrera wrote:
> Jarek's statements reflect my own sentiments as well.
> To address your concern about key collisions, I don't think that it 
> will happen if modules get their own resource file.  It was never a 
> problem for me.
> Regards,
> Alan
> On Feb 27, 2008, at 7:57 AM, B.J. Reed wrote:
>> Thanks, each plugin/module will have its own resource file in the 
>> plugin/module jar now.
>> The MessageFormat and varargs were very helpful.  The code is much 
>> simpler now.
>> For the message keys, I'm just looking for some way to have a unique 
>> naming scheme and the group id/module/abbreviations should do that 
>> (for now at least).  With a scheme not based on the module name, I'm 
>> afraid of the following: since each module has its own resource 
>> bundle, keys in different modules could have the same name and 
>> everything would work fine, but if users reference a key and it's not 
>> unique.....what else can we use to help make these keys unique across 
>> modules?
>> --B.J. Reed
>> Jarek Gawor wrote:
>>> Some thoughts:
>>> 1) Each module or plugin should have its own resource file.
>>> 2) Messages should be formatted using java.text.MessageFormat. The
>>> substitution arguments should be arbitrary objects (not just strings)
>>> and should be passed using varargs.
>>> 3) As soon as we encode the module or group id into the key or
>>> whatever, it will become invalid or inaccurate. It's a maintenance
>>> mess in my opinion. I think the key should just be a simple string
>>> without any additional encoded information. We can inject some extra
>>> info as the message is displayed but the key should be very simple.
>>> Jarek

View raw message