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

[Rod J. <rod...@in...>]

Tony,

> Very quickly though, in response to your question of "Wouldn't this mean
extending MessageSource with overloaded getMessage versions that feature an
errorArgs parameter?".  Yes,
> my changes initially started out with changing the MessageSource interface
(and the implementations) to handle passing in an "Object[] errorArgs"
param.
I'm fine with this.

> From there it let to some changes elsewhere, including looking at the
Errors object.
> One thing that should probably discuss is the concept of a single message
source.
> Initially I though a single message source would be fine, but as this is a
framework I've since
> changed my opinion.  My opinion now is this.  We can leave each Context to
have it's
> own single message source, but we can allow configuration (using the
framework's bean
> factory code) to allow other classes to have whatever message SOURCES they
need.
> Let's look at this as an example.  One of my code proposals is to add an
Exception class into the framework
> that will be able to resolve messages from a ResourceBundle.
I'm not so keen on this. I think when throwing an exception, code should
only provide an error code. It won't necessarily know about how messages are
resolved: this is a presentation issue.

Maybe a compromise would be to have a fallback approach, in which the
ErrorResolver implementation, if it failed to look up a message for an
exception's error code, looked for a ResourceBundle called
messages.properties in the same package as the exception. I think this would
allow what you propose, but still permit the use of an override at framework
level.

Btw, the present approach isn't limited to a single message source:
MessageSources nest.

> BTW - I think we should have 2 overloads for the methods that allow a
Locale to be passed in.
> If it is passed in we use it.  If it is not passed in, fall back to the
"defaultLocale".
> Currently the way I've coded the "defaultLocale" is whatever Java resolves
to.  This needs to be changed
> to work with the changes that have been made for the Locale to be passed
in from HTTPRequests.
> This definately needs to be discussed (shouldn't be a big deal).
Sounds reasonable.

Regards,
Rod