Generating feedback messages on server-side vs client-side?
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 acollecting 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.
[3679 byte] By [
jdupreza] at [2007-11-27 10:22:33]
# 1
> 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.
This doesn't address your actual question, but you should seriously consider performing a full verification test on the server side in addition to proactive client-side verification. Otherwise you're leaving yourself open to client-spoof attacks that bypass your verification.
# 2
As to your question, how many discrete error messages are we talking about? Can you not just use html tags?
# 3
> 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).
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.
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.
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.
A parameter error message would be something like the following....
"The customer name field can not be longer than 15 characters".
In the above the "15" would a parameter.
# 4
> 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.
# 5
> This doesn't address your actual question, but you
> should seriously consider performing a full
> verification test on the server side in addition to
> proactive client-side verification. Otherwise you're
> leaving yourself open to client-spoof attacks that
> bypass your verification.
I maintain both server and client apps, on a secure intranet, so attacks are not an issue, but the client app might be buggy and forget one check, so you have a point...
> how many discrete error messages are we talking about? Can you not just use html tags?
A few dozens. That may increase with new business rules that will unavoidably be requested over the maintenance life of the apps, but will likely remain under the 200.
I'm not sure I understand your HTML tags suggestion. The problem is not so much with the formatting but with the location where formatting belongs. I deem it belongs to the client side, whereas the diagnosis is performed on the server side, and I am worrying about the cleanest way to maintain that (cf previous reply).
# 6
> 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?
Depends.
Business rules errors - yes.
Programming errors - no.
In a well structured system there will be more of the latter than the former.
>
> > "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).
For a given id it is defined to have certain parameters.
Regardless of whether the backend returns them or not. But it should. If it doesn't then the message is still displayed with empty values.
You can of course engineer your own solution to do basically the same thing. But in either case a list of parameters is still returned.
