When the message is evaluated you have an access to the stack, try this:
errorMessage.invalidRange=${getText(fieldName)} must be between ${min} and
${max}, current value is ${bar}.
Then have in your resources:
bar=Your display name for field bar
foo=Your display name for field foo
IMHO, Struts 2 should drop the message as a required field in validation (esp.
Annotations) and provide meaningful defaults for all i18n keys like:
errorMessage.required=${getText(fieldName)} is required.
Lukasz
-----Original Message-----
From: Jon Wilmoth [mailto:[EMAIL PROTECTED]
Sent: Friday, June 15, 2007 1:18 PM
To: [email protected]
Subject: Fw: [S2] validation error message params w/ message key?
I posted this message on the user list and have since done some digging that
leads me to believe there is support for parameterizing validation messages
while still using a message key. I believe the way to achieve this would be to
define a resource bundle with the following entry and the subsequent xml
validation config:
errorMessage.invalidRange=bar must be between ${min} and ${max}, current value
is ${bar}.
<field-validator type="int">
<param name="min">6</param>
<param name="max">10</param>
<message key="errorMessage.invalidRange"/> </field-validator>
That being said I think there's a chance to do things differently & in a more
standard way that a) improve S2 adoption b) reduce the number of resource
bundle entries and subsequent maintenance work.
I looked at com.opensymphony.xwork2.validator.validators.ValidatorSupport's
getMessage method (v 2.0.2) and the following lines appears to be the
candidates for improvement.
message = validatorContext.getText(messageKey, defaultMessage);
is followed by
message = TextParseUtil.translateVariables(message, stack);
Instead I think
getText(String key, String defaultValue, List args);
or
getText(String key, String defaultValue, String[] args) could/should called
(with the args being defined in the xml config file &
TextParseUtil.translateVariables being called for each configured message
parameter defined in the config file)
which would look like <param position="0">${min}</param>. The message resource
bundle entries then could be in a java.text.MessageFormat standard format.
This would allow for the re-use of a message key. So instead of:
errorMessage.invalidRange.bar=bar must be between ${min} and ${max}, current
value is ${bar}.
errorMessage.invalidRange.foo=foo must be between ${min} and ${max}, current
value is ${foo}.
errorMessage.invalidRange.foo=foo must be between ${min} and ${max}, current
value is ${foo}.
I could have one MessageFormat standard entry like so:
errorMessage.invalidRange={0} must be between {1} and {2}, current value is {3}.
Thoughts?
----- Forwarded Message ----
From: Jon Wilmoth <[EMAIL PROTECTED]>
To: Struts Users Mailing List <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2007 3:44:54 PM
Subject: [S2] validation error message params w/ message key?
The DTD (http://www.opensymphony.com/xwork/xwork-validator-1.0.2.dtd) for the
xml validation file definition doesn't appear to support error message
parameters. How does one pass msg parameters when using the message key (which
I assume is a i18n message file key)?
Using the example on http://struts.apache.org/2.x/docs/validation.html, instead
of
<field-validator type="int">
<param name="min">6</param>
<param name="max">10</param>
<message>bar must be between ${min} and ${max}, current value is
${bar}.</message> </field-validator>
I'm trying to do
<field-validator type="int">
<param name="min">6</param>
<param name="max">10</param>
<message key="errorMessage.invalidRange">
<param position="0">${min}</param>
<param position="1">${max}</param>
<param position="2">${bar}</param>
</message>
</field-validator>
<!ELEMENT message (#PCDATA)>
<!ATTLIST message
key CDATA #IMPLIED
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
