Phil Steitz wrote :
The problem with that is that generic handlers that display messages would
not work. I like the idea of carrying the data along, though and exposing
it, as well as providing translate (see
http://svn.apache.org/viewvc/jakarta/commons/proper/math/trunk/src/mantissa/src/org/spaceroots/mantissa/MantissaException.java?view=markup
)
and getMessage(Locale) methods. That gives client apps the most
flexibility. What do you think, Luc?
Trying to synthetize all use cases, here is what I think is expected by
everyone who has expressed views :
1) allow application level code to contribute to/configure message
building
2) allow low layers to build messages with variable parts
3) allow localized messages
4) expose message parts (key and parameters)
5) allow handlers using only no arguments getMessage() to work as usual
6) use a mechanism robust enough to work even in case of code changes
and missing localization data (of course in degraded, i.e. non
localized
mode)
The following proposal is an attempt to address all these points.
Two main classes would be used: the MathException base class and a
MessageFactory base class. MathException would delegate to
MessageFactory the task to build the message from its String key and
Object[] parameters (point 2). Both the key, parameters and message
would be available with appropriate getters (point 4 and 5). A static
method in MathException would allow upper layers to prepend a customized
MessageFactory instance (point 1) in front of already registered
factories following a chain of responsibility. The initial chain would
contain three different MessageFactory instances :
- a LocalizedMessageFactory using the key to retrieve a pattern from
a ResourceBundle for the default Locale (Locale.geDefault()) and
MessageFormat to build the message (point 3)
- a NonLocalizedMessageFactory using the key directly as a pattern
for MessageFormat
- a RawMessageFormat simply concatenating everything with toString
The chain of responsibility is intended to provide robustness (point 6):
the first message factory providing a non null message is used. If a
factory fails, the next one is used. The last factory cannot fail.
A user who simply wants to get messages localized for a Locale which is
not the default one would therefore only need to do :
MathException.prependMessageFactory(new
LocalizedMessageFactory(myLocale));
This would work even if its locale is not supported as its factory would
always fail but the following ones would be triggered as needed.
I think an appropriate policy would be to always use US-english patterns
as keys as it would allow to get meaningful messages even if everything
else fails, and as it would help the translators tasks.
Does this seems sensible ?
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
