Generating feedback messages on server-side vs client-side?

Question

Hello,
I am maintening a client/server app (Swing client, no Web pages), basically an order processing system. The biggest part of it is to verify the conformity of orders to a set of business rules.
As usual, some of the verification can be made early on the client-side, but most of the verification work is done on the server-side. My problem is, I don't find a very satisfactory way to generate the user feedback to be displayed to the user.
If I generate them as Strings (or HTML Strings) on the server, where the rules are checked, this constrains the way these can be displayed on the client, and makes maintenance of the human-readable strings awkward and risky (e.g. localization, or restructuring the messages, like sorting them by severity vs by affected entity).
If I generate them on the client, I need a class to vehicle the diagnosis form server to client, and this class and its usage tends to become awkward in itself.
Concretely:
The initial version generated human-readable strings on the server, which assumed the messages would be displayed as strings in a JOptionPane.
Moreover, the logic evolved to distinguish between Info, Warning and Error messages, to be displayed in different colors of course, so the Strings evolved into HTML Strings, still generated on the server.
Do you think this approach is safe?
I'm afraid a simple maintenance of the strings (like, sorting the errors by severity vs by affected entity, filtering the strings,...) becomes a server-side development, which is a bit more risky (I would have to review code ownership policies, VCS and code-sharing policies,... to let less experienced staff maintain the darn error Strings).
Moreover, if the client app evolve to display the errors in complex widgets (colors in a tree/table, with tooltips), the server-side generated HTML strings would be constraining : coloring or tooltipping Tree nodes would now mean parsing the String to extract the "error level" or the "affected entity", which is quite inelegant and inflexible.
My current idea was then to use a collecting parameter to collect validation messages on the server, and traverse them on the client:
I designed a naive ErrorList class, with methods such as addInfo(String), addWarning(String), addError(Strin), and the corresponding getErrors() and hasErrors()/hasWarnings() methods. I can then generate the Strings (or whatever widget fits better, such as a table) on the client side. Moreover, I can add the client-side messages to the bag...
All nice and well, but the customer requested that the error messages be formatted such as "The profile <profile name in bold> does not allow you to order service <service name in italics>".
To format that on the client, my ErrorList class should evolve so that for a given message, I know that the error is of type ("incompatibility between profile and service", that the service is X and the prodile is Y).
That forces me to add in some API (shared by the client and server) the list of error types, and the data each error type requires.
I can evolve my ErrorList API to break up messages into a DTO giving (type, affected entity, arg1, arg2,...), but anyway the server and client have to agree on what is arg1, etc... which is a hidden coupling.
Do you use and recommend such an approach for server-to-client feedback: a collecting parameter in which the server puts the "errors", and that the client traverses to display the messages)? In particuler, isn't the coupling hard to maintain?
Thansk in advance,
J.

Answer 1

Presumably you are not over-engineering in that you
know that localization is a problem rather than that
in all possible worlds in might be.I appreciate your delicate questioning... I definitely have read much ruder ways to say YAGNI to a poster...
I do know that the customer will knit-pick to reword and reformat the messages. But I won't need to translate the messages to other locales. In that regard, I ackowledge my usage of the term localization is a bit liberal, but I think I should to extract the messages from the code, to be able to maintain them separately - keeping only experienced staff's hand in the server's core.
That is actually my question 1): from experience, is it worth the trouble to separate code and human-readable text, knowing that the text WILL have to be maintained?
Question 2 is about how to implement this.
In particular, the built-in MessageFormat templating engine, though originally introduced for i18n, actually suits my needs (including MessageFormat-built messages) and developing or using any other templating engine would probably be an overkill.
Given that there are two types of messages.
1. Fixed
2. Parameter driven.
In both cases you need to return an id which
identifies the message. The client has a locale
specific resource source which has a matching id.
From there a string is derived.
If the error requires parameters then the string has
formatting values in it and it s written with the
returned parameters. See java.text.MessageFormat.Yes. In some cases I don't know yet whether parameters will be displayed. I can conservatively assume the message requires a MessageFormat, and give all parameters (in my case, use rname, profile name, command id, service name, order date,...), whether thay are displayed or not in the final message.
Be warned you MUST deal with the possibility that a
id does not exist in the client, if so have a default
message that displays the id and any parameters.Good point.
"The customer name field can not be longer than 15
characters".
In the above the "15" would a parameter.Yes. The trouble is, you have to document somewhere (Sun suggests in the resource bundle file), that for error id #123456, the number of characters in in the '{0}', or in the {6}. I don't feel confident with that (this is the "coupling" part in my question 2�).
Thanks for your advices.