Gerrie,
This is an interesting effort, but I think it would cause serious
problems if we externalized ALL strings. I'm all for externalizing
error messages to support localization efforts. But for many things
externalizing strings would make the code more complicated, error
prone, and difficult to maintain, and that is a big problem for a
project like OFBiz. Developer efficiency and avoiding complexity is
very important in order to be able to handle a large volume of
business logic with as little code as possible, and among a small
group of people.
On the property name issue: I'd prefer names that do not use dots for
word separators because in some code, like in FreeMarker ${} and in
the various OFBiz XML file attributes that support the Flexible
String Expander with the ${} syntax, it causes problems because dots
are interpreted as meaning the symbol to the left of the dot
represents a Map name and the one to the right of the dot represents
a Map entry key. Actually, we really should change all of the
existing ones that have dots to use capital letters to separate the
words instead.
I hope that helps... though I recognize that especially the first
comment doesn't really make it easier...
-David
On Oct 6, 2006, at 11:40 AM, Gerrie Myburg [ MTN - Innovation
Centre ] wrote:
PLEASE READ! Not the end of the world, but if I start booking in the
code a lot of people can be very pissed off if they don't agree with
what I need to do.
Externalizing strings.
I can now externalize all the strings in the ofbiz code base. I
used the
antlr parser generator and a JAVA 1.5 grammar to write a program to do
it.
The problem I now have is that there is more than one resource file
per
module and that the format for the key strings differs from one module
property file to the other module property file.
The first question is the number of property files per module. Can we
not have one property file per module? I understand that the different
files create a namespace effect, but this same effect can be gotten by
encoding the namespace in the property key. Eg
error.ui.get.lost=You made a mistake. Go to the start and try again.
If we do this then all the property strings can be in one file. I
would
prefer one property file per module with the namespace encoded as part
of the key.
The second issue is the key string format. I need to now what is the
preferred key string format please? There are 2 formats in general
Example
1. Name1Name2Name3 - like a java id with the first letter in caps
2. name1.name2.name3 - '.' in place of the spaces
Some of the keys also contains contextual information eg
error.module.name1.name2
I can try to place contextual information in the generated keys for a
message when I run the program that extract the strings, but don't
hold
your breath as this is VERY hard to do in principle.
If I can get some consensus on the format of the key strings then I
will
go and change all the key string and property files to the same
format.
If nobody responds to this mail then I will change all the key strings
as in format 2 above. It is more readable for me. THIS CHANGE AFFECTS
ALL THE FILES IN ofbiz!
There are more problems with the message string constructions that I
never foresaw and cannot find a simple way to resolve. This relates to
constructs like
String message = "this " + ( isThere == null ? " is " :
isThere.toString) + ".";
I need to go and rewrite the message by hand in such a way that it can
be translated to other languages. The above example does not happen
often. I cannot guarantee that there are other messages that are
constructed in a similar manner. We will just have to go through the
code looking for other strange examples.
One disadvantage of programmatically restructuring code is that it is
hard to deal with exceptions. One example of exceptions is the
construction of strings contacting
1. SQL
2. html
String. If no one complains about this then I will extract these
strings as well.
NOTE: This e-mail message is subject to the MTN Group disclaimer
see http://www.mtn.co.za/default.aspx?pid=34411
