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
