RE: [Springframework-developer] ErrorCoded changes integrated

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

After rethinking the "Object getControlledBy()" last night by first task today was to remove it from the MessageSourceResolvable interface and tell you about it.  I agree, it's totally something the Impl knows about and it was an artifact from refactoring I did on my initial coding.  Please remove it when you are making your changes.
In regards to the call to "getMessage()" (no params) within the toString() method.  I have no objection to this being removed.  It was put there to conform to what was in some code I saw that Rod had done to show internal state of an object (prior to us having the msg resolve).
No objections to moving around of the params, or naming them consistently.
I'm also not married to the keeping of the getLocale() on the MessageSourceResolvable interface.  I think you are right that most of the time it won't be needed - I leave this one up to the group.
As far as having the overload "getMessage(MessageSourceResolvable)" on the MessageSource interface, I also concur that if you remove the getLocale() from the MessageSourceResolvable interface, this overload should also be removed.
Very good feedback.  Thanks.
 jürgen_höller_[werk3AT] <jue...@we...> wrote:Tony,

Let me move this discussion to the developer list.

I consider "getControlledBy()" a method of a MessageSourceResolvable implementation, not of the interface itself. I simply don't see a reason for it needing to be in the interface. The toString() method is an implementation detail, not to be respected in the interface. A concrete MessageSourceResolvable can add any internal properties that it likes to, or be implemented as inner class to have access to the state of the surrounding "controlling" class.

Furthermore, your MessageSourceResolvableImpl.toString() implementation tries to actually resolve the message. IMO it shouldn't: MessageSourceResolvable(Impl) is a message specification, a parameter object used in the MessageSource interface. It shouldn't in turn know about the MessageSource interface, this creates an unnecessary two-way association. For use within the framework and especially within the validation package, a parameter object with a simple toString() is perfectly sufficient.

Concerning the locale property in the resolvable, I don't think that this does make sense. The locale is an attribute used at message resolution time, not at message creation time, at least not in the 99% normal case. Introducing double support here by giving MessageSourceResolvable a locale attribute is confusing and inconsistent with locale handling in the rest of the framework. I plead for one straightforward approach.

I'm aware that "getMessage(MessageSourceResolvable)" is in the MessageSource interface. It's just that this overloaded version is not necessary once that MessageSourceResolvable does not support a locale property anymore. I've also adapted the parameter order in the other getMessage versions, i.e. moved the locale to the end, to reflect the special role of the locale.

I consider the above mentioned simplifications necessary for keeping the framework clear and straightforward. We can add extra sophistication in the form of specialized subclasses in the future - if we ever need it. Thus, I've already applied the simplifications, including some according parameter renaming (no "error" names in the message source core) and slight refinement of the validation API (adding support for error arguments to the reject methods).

I will check this stuff in soon, together with the mock object moving and the minor new features described in a previous mail - if you haven't any strong objections.

Regards,
Juergen


-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...] 
Sent: Monday, March 17, 2003 12:15 AM
To: jürgen höller [werk3AT]; rod...@in...
Subject: Re: ErrorCoded stuff ready for integration


Juergen, 

In response to your questions: 

-- What does "getControlledBy()" return? It returns an object, that being the object that it the "parent" or "owner" of this MessageSourceResolvable. This is a handle back to an object that might have a MsgSourceResolvable as an internal attribute. It allows the MsgSourceResolvable to make calls back to the parent if need be. Right now, you will see in the MessageSourceResolvableImpl that the toString() method uses this. 

-- I'm not sure why the resolvable contains a locale. This may be a bad example, but it's what I can come up with right now. Suppose a request comes in for Locale A that contains an eror and we don't want to resolve it right now. Let's say we store it in the database. Suppose later on we want to then reconstitue it to merely log the error to a file (thus no "HTTPRequest" was received for this to happen). Storing the locale with the object allows us to do this. 

-- Remove the "getMessage(MessageSourceResolvable)" method. Actually this is on the MessageSource interface, not on the MessageSourceResolvable interface. Similarly to being able to resolve a message from a MessageSource via getMessage(errorCode, errorArgs, locale, defaultMessage) why not allow the caller to just pass in a MessageSourceResolvable? They could do this by newing one themselves - an unlikely use of it, or by passing in one they already have a handle to - see examples in the code that already do this. Remember, a MessageSourceResolvable basically is just the 4 attributes you are passing into the "getMessage(errorCode, errorArgs, locale, defaultMessage)" method anyway. Let the caller decide what method is easier for them to call.


-----Original Message-----
From: Tony Falabella [mailto:ton...@ya...] 
Sent: Sunday, March 16, 2003 11:38 PM
To: spr...@li...
Subject: [Springframework-developer] ErrorCoded changes integrated


I have just integrated a lot of changes to accomplish 2 main goals:
1) To resolve messages from a MessageSource (ResourceBundle) using a "code"+locale
as the key that message.
2) To allow messages being resolved to take arguments in and have them be substituted
in the message returned.
I'll start with the high level description of what I've done. First, I changed the
MessageSource interface to have the following API:
String getMessage(MessageSourceResolvable resolvable) throws NoSuchMessageException;
String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException;
String getMessage(String code, Locale locale, Object args[]) throws NoSuchMessageException;
String getMessage(String code, Locale locale, Object args[], String defaultMessage);
You'll notice 2 new overloads that take in a "MessageSourceResolvable". This is a new
interface I've introduced and it has this API:
public Object getControlledBy();
public String getDefaultMessage();
public Object[] getErrorArgs();
public String getErrorCode();
public Locale getLocale();
Basically, the thought is anyone that wishes to have something resolve it's messages from a MessageSource
need only implement this interface and the MessageSource will know how to return the message.
Notice that there are no setters on this interface - thus from the point of view of
a method receiving a MessageSourceResolvable object it is immutable. 
Generally anyone implementing this interface will provide appropriate constructors taking in similar arguments. 
The "MessageSourceResolvableImpl" class is a default implementation of this interface with the 
appropriate constructors and a good toString() method for showing the internal state.
Also notice the "getMessage(MessageSourceResolvable resolvable, Locale locale)" overload.
Since a MessageSourceResolvable is immutable it's values will generally be set only during
it's construction. It is quite possible that the MessageSourceResolvable might be
created during one HTTPRequest. The message to be displayed to the user might not occur
until another HTTPRequest arrives. Since the Spring Framework accommodates being able to
change the Locale on a HTTPRequest level, you need the ability to pass in a locale to the 
getMessage(...) method. This version of the method will use the locale arg passed in rather
than any locale attribute value that may have already been stored on the immutable MessageSourceResolvable.
for message resolution.

Also, a convience class named com.interface21.util.ObjectArrayUtils was introduced. This is
a static helper class that aids you in converting scalars into Object arrays. Perhaps useful
in the creation of the "Object[] args" parameter.


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer