[Springframework-developer] FieldError: TypeMismatch - generic message

[Daniel M. <dm...@tc...>]

Is there a way to specify a generic message for a single type on type
mismatch for FieldErrors? For example I would like to define a message
resource like this:

typeMismatch.integer=3DValue must be an integer
or
typeMismatch.com.example.SomeType=3DValue must be a valid identifier for
SomeType

The second woule be optimal (for types with matching names, but in
different packages). Currently I have to do this for each field:

typeMismatch.objectName.fieldName=3DField on Object must be [sometype]
or
typeMismatch.fieldName=3DField must be [sometype]

In my opinion, that is severely limiting. I must at least specify a
message resource for each and every field that is not a string. Granted,
my message could apply to multiple fields if I happened to have two
objects with the same field name, but I think this would be more prone
to displaying the wrong message for a field of a different type that
happened to have the same name.

While I'm on the subject, I might as well vent my other peeve with this
message name construction pattern. Why have typeMismatch be the "parent"
element in the message name? Wouldn't it be more logical to have the
message signature be "objectName.fieldName.code"? I think this is a flaw
in the Spring-centric method of message resource resolution. I would
expect the error messages to be resolved in the following order:

Most specific (first)

objectName.fieldName.typeMismatch
objectName.typeMismatch.typeName
objectName.typeMismatch
typeMismatch.typeName
typeMismatch

Least specific (last)

That way the name is resolved from first to last: field on object
(implied type) to type on object (could be nice) to object mismatch (I
would rarely if ever use this) to mismatch for type (very useful) to
typeMismatch (to keep all unhandled mismatch messages nice and
user-friendly). Note that "typeMismatch" is a code that would need extra
"arguments" (typeName), while the "required" code wouldn't necessarily
need the type. However, it wouldn't hurt to have the same type of
message resolution pattern. Who cares if it looks for a message with the
name "objectName.required.java.lang.Integer" or
"required.java.lang.Integer"? Most people would simply not define those
messages.

I realize that the changes suggested here are revolutionary, but I think
it is imperative to make the change as soon as possible (pre-1.0) to
have minimal frustration in the future as Spring becomes more widely
used.

Thanks,
Daniel Miller