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

[Tony F. <ton...@ya...>]

Juergen, 
You have some very valid points.  Unfortuately I have limited time this morning to reply with any detail.  I will respond more tonight. 
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.
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.  The actual code
for doing this resides in a "MessageSourceHelper" class, that implements the MessageSource,
ParameterizableErrorCoded (new subint of ErrorCoded that takes errorArgs), 
and ApplicationContextAware (for a callback from the context after a bean gets loaded into
the context).  This helper can be used by anyone that wishes to gain access to a MessageSource.
In my case, an abstract class "NestedCheckedExceptionWithMsgSource" knows how to forward
calls to this helper to resolve messages. 
It's quite possible that for this new Exception class that the user wants to isolate
certain types of messages into various text files.  So for example messages with
packages like the following might come from various sources:
com.int21      --> File A
com.int21.core    --> File B
com.int21.core.NestedCheckedException --> File C
com.int21.core.subpack   --> File D 
It's my proposal then, to allow configuration in the applicationContext.xml file
to create a "tree" hierarchy of what file gets associated with what package or class 
you are dealing with.  BTW - This Hierarchy code is modeled on how log4j does things 
and will be ported from it.  Unlike how the user creates a logger in log4j (ie: Logger = new Logger(Clazz.class.getName());
the MessageSourceHelper's "private Object controledBy" object name will be internally used
as the key for what file to resolve to. 

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). 

Let me formalize my thoughts a bit more tonight to give you a better response.  I can also send
over the changes that I have to you so we can work through an integrated solution. 
Tony 

  
 jürgen_höller_[werk3AT] <jue...@we...> wrote: Hi Tony,

Regarding your proposed changes to the Errors interface:

> Right now, I believe the API to obtaining messages for 
> 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.
> 
> My changes should address both these issues. Also, I am 
> attempting to add a subclass to the NestedException class 
> (that merely calls a helper
> object) that will allow Exceptions themselves to obtain their 
> 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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer