I think perhaps you misunderstand. I know nothing about stored
procedure calls to get messages. I have a properties file called
clientmessages.properties that has the messages used by the network
client code, and they are loaded directly as a resource.
I have updated splitmessages.java in the build directory to copy
messages from messages_XX.properties over to
clientmessages_XX.properties (for each locale).
What I'm doing right now is if there are messages that are new for the
client code and not currently being used by the engine, I am manually
adding those to clientmessages.properties, and splitmessages is then
appending to this.
What I am suggesting is that I put *all* messages in
messages.properties, and the splitmessages.java copies them all over.
No manually adding messages to clientmessages.properties any more.
It will likely increase the size of derby.jar by ~200 messages x ~80
bytes each or 16K. The derbyclient.jar will increase by 16K also (this
is regardless of what approach we choose), but this is offset by the
fact that hardcoded strings are now being removed from the Java code.
David
Kathey Marsden wrote:
David W. Van Couvering wrote:
I would like to understand what resistance there might be to putting
all messages in the single properties file, messages_XX.properties,
and using a build script to copy over the appropriate messages for the
client.
How much would this increase the size of client and server? I had
always thought that if it didn't cause too much bloat, this would be a
good solution, because it might also potentially mean we could get rid
of the horrible stored procedure call for client messages. I have
always been big fan of build based code sharing. All the other
strategies seemed awfully cumbersome to users and developers to me.
Kathey
