RE: error with parameters + Locale specific message parameters

["Jones, Dean" <dj...@refco.com>]

Craig,

Using parameterized errors is something I have also been trying to do,  and
I had a
simple implementation of addError(String, Object[]).  One key thing for
parameterized
TYPED Locale specific formatting is the following change to
MessageResources.java. It
is a bit odd,  as the MessageFormat does not use the Locale if it already
has
internally constructed the formatting machinery.  This will make it work
properly,
and you can use the mechanism for messages like:  The Date is {0,date,full}
and
have it print the date in the proper Locale long formatting.  Of course,
there is no
way to pass TYPED message parameters from the <struts:message> tag,  is
there ???
{ I am not quite sure I can even imagine how... } except instead if we
specify
the ``args'' as some type of bean property.  Thinking about that one...

Dean S Jones
-----

public String getMessage(Locale locale, String key, Object args[]) {

	// Cache MessageFormat instances as they are accessed
	MessageFormat format = null;
	String messageKey = getResourceKey(locale, key);
	synchronized (formats) {
	    format = (MessageFormat) formats.get(messageKey);
	    if (format == null) {
		String formatString = (String) getResource(locale, key);
		if (formatString == null) {
		    if (returnNull)
			return (null);
		    else
			return ("???" + key + "???");
		}
		if (locale != null) {
			// The Locale HAS to be set BEFORE the format
string!!!
			format = new MessageFormat("");
			format.setLocale(locale);
			format.applyPattern(formatString);
		}
		else {
			format = new MessageFormat(formatString);
		}
		formats.put(messageKey, format);
	    }

	}
	return (format.format(args));

    }

----------------------------------------------------------------------------
---------------
>It is a good idea.
>
>I'm actually going to checking in a slightly extended version of this idea.
The
>new ActionErrors object will have the following new capabilities:
>
>* You can save parametric replacements along with your message
>  keys so that you can use {0}, {1} type substitutions.
>
>* You can optionally associate individual error messages with
>  individual property names, or just leave them global.  This gives
>  the presentation layer the ability to do more interesting things
>  than just display all the errors at the top of the page.
>
>Craig