RE: [Springframework-developer] purpose of code in Errors.rejectValue()

[<jue...@we...>]

Hi Tony,

Regarding your proposed changes to the Errors interface:

> Right now, I believe the API to obtaining messages for=20
> anything in the framework is limited in 2 ways:
> 1)  Does not allow parameters to be passed to it.
> 2)  Some of the APIs do not allow a Locale to be passed into them (the
> Errors.rejectValue(...) is a good example.
>=20
> My changes should address both these issues.  Also, I am=20
> attempting to add a subclass to the NestedException class=20
> (that merely calls a helper
> object) that will allow Exceptions themselves to obtain their=20
> messages from a ResourceBundle.

> rejectValue(String field, String errorCode, String message)
> rejectValue(String field, Locale locale, String errorCode, Object[] =
errorArgs, String defaultMessage)

You're right concerning the opportunity for message arguments. But I'm =
not sure about resolving the message from some specific error messages =
file, completely separated from the ApplicationContext and its =
MessageSource. Tbis would be inconsistent with the rest of Spring's =
message handling.

What do you intend to achieve with the Locale parameter to rejectValue? =
Do you intend to resolve the message immediately? This is not what =
localized messages is about. You need to resolve the message with the =
display locale, i.e. the locale of the user that actually sees the =
message.

If you simply want to generate a message including message arguments for =
a single language, then do so in your validation code and give your =
completed String result to the simple rejectValue version. The errorCode =
can be used for a short general identifier instead of a message key, as =
you've pointed out.

If you want to have localized messages with message arguments, then use =
the rejectValue version with errorArgs: The errorCode has to match the =
MessageSource key (i.e. ResourceBundle key in most cases) but simply =
gets stored, and so do the errorArgs. The final message gets constructed =
by the user of the Errors instance, e.g. the BindTag instance that =
prepares the Errors state for web UI usage via BindStatus. So the =
rejectValue implementation must not try to construct the final message, =
as it is not and should not be aware of the current user's Locale.

Therefore, the signatures should rather look as follows (note: no Locale =
parameter):
- rejectValue(String field, String errorCode, String message)
- rejectValue(String field, String errorCode, Object[] errorArgs, String =
defaultMessage)

Finally, how do you intend to merge the message from the resource bundle =
with the error arguments? Keep in mind that this should not happen in =
the rejectValue implementation! Taking BindTag as example again: =
Currently it simply tries to resolve the errorCode and the given message =
via the ApplicationContext's MessageSource support. How do you intend to =
make this work with error arguments? Wouldn't this mean extending =
MessageSource with overloaded getMessage versions that feature an =
errorArgs parameter?

Let's discuss this issue before you get your stuff into CVS, for =
clarity's sake. I've also made some changes to the Errors approach (as =
you're probably aware), especially for usage by the web package, so we =
should definitely synchronize our efforts!

Regards,
Juergen