Joe,
There have been some subtle changes especially within the Validator, for
example the xml you no longer specify arg0-arg3, you specify an arg then
give it a position attribute to change message key info for display.
A couple things I've had to do that seem pretty tedious and could likely be
a target of some good refactoring. I've done previous development where I
stored all errors in an ActionErrors object under its default key in the
session, however having to put html code into my properties file was not
something I wanted to do on my new app. So what I do now is store
everything in ActionMessages, and I store messags/errors under different
property values within that object. So when I go to display errors my jsps
look something like:
<logic-el:messagesPresent message="true" property="GLOBAL_ERROR">
<h4 class="Red">Errors:</h4>
<ul style="margin-top: 0; margin-bottom: 0;">
<html-el:messages id="error" message="true" property="GLOBAL_ERROR">
<li><c:out value="${error}"/>
</html-el:messages>
</ul>
</logic-el:messagesPresent>
or GLOBAL_MESSAGE for messages. However this was a significant challenge to
accomplish. Since the commons-validator seems to store errors under random
properties within the ActionErrors object I needed to put this into my
validate method of ValidatorActionForm:
ActionErrors validatorErrors = super.validate(mapping, request);
ActionErrors errors = new ActionErrors();
if (validatorErrors != null) {
for (Iterator i = validatorErrors.get(); i.hasNext();) {
ActionMessage message = (ActionMessage)i.next();
errors.add(Globals.GLOBAL_ERROR, message);
}
}
Note my use of Globals.GLOBAL_ERROR is my own set of Globals within the app.
Is there somewhere I can specifically tell commons-validator what property
to store errors it finds under? I couldnt find it but it may exist.
Secondly I did have to overwrite the processValidate method of my request
processor to store the results of the validate() method into session scope
under the Messages key instead of Errors.
Quite a bit of work just to get messages to show up it seems :)
Thoughts/Comments?
Oh and on a sort of related rant, within the xml commons validator why in
the world can you not substitute in runtime values? IE if I am validating
an email address I want to do something like:
{0} is not a valid email address
and within that {0} substitute in the value the user submitted, all within
the xml.
So something like
<arg value="emailAddress" position="0" runTimeValue="true"/>
-David
----- Original Message -----
From: "Joe Germuska" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>; "Struts Mailing
List" <[EMAIL PROTECTED]>
Sent: Wednesday, June 23, 2004 7:49 AM
Subject: Re: New Validating system instructions?
> At 9:18 PM -0600 6/22/04, David Erickson wrote:
> >Just wondering if there are any docs up on how the validator works in the
> >new nightly builds of struts... trying to transition everything to using
> >ActionMessages and storing the errors/messages under different keys
within
> >that object, just wondering how to do that using the validator.xml
plugin.
> >Thanks,
> >David
>
> The way in which validator integrates with Struts has not changed.
> Validation errors are still "errors" and are still stored in request
> scope using the key org.apache.struts.Globals.ERROR_KEY (which has
> the literal value "org.apache.struts.action.ERROR") This is the
> default location where the html:errors and html:messages tags both
> look for an ActionMessages object.
>
> More generally: the difference between the classes
> ActionErrors/ActionError/ActionMessages/ActionMessage has *absolutely
> nothing* to do with the difference in behavior in
> Action.saveErrors(...) and Action.saveMessages(...)
>
> The difference between the classes is zero -- all behavior in
> ActionErrors was pushed up into ActionMessages and all behavior in
> ActionError was pushed up into ActionMessage. This was done in the
> attempt to clearly signal that these classes can be used to pass any
> kind of messages from the controller to the view -- errors being only
> one kind of message.
>
> The difference between saveErrors(...) and saveMessages(...) is
> simply the attribute name under which the ActionMessages object is
> stored, providing two convenient default locations for storing
> controller messages for use by the view. If you look more closely at
> the html:errors and html:messages tags, you can actually use them to
> get an ActionMessages object from any arbitrary attribute name in any
> scope.
>
> While we're clarifying, the difference between html:errors and
> html:messages is purely in syntax and model -- both tags *default* to
> look for an ActionMessages object under Globals.ERROR_KEY despite the
> difference in names. I wasn't part of the history, but I'm assuming
> that around the same time that people were realizing that there's
> more than one kind of message to pass, they also realized that
> sometimes you want more flexibility in displaying them.
> html:messages provides more flexibility at the cost of more typing.
>
> I hope this helps to clarify things. I would strongly encourage
> people to have a look inside the Struts source code, as it's really
> quite clear when you look under the hood. You can see what happens
> in validation by examining the "processValidate" method in
> RequestProcessor:
>
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/struts/action/RequestProcessor.java?view=markup
>
> You can see what happens with saveErrors and saveMessages by
> examining those methods in Action
>
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/struts/action/Action.java?view=markup
>
> You can see what the tags do by looking at their respective source files:
>
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/struts/taglib/html/MessagesTag.java?view=markup
>
http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/struts/taglib/html/ErrorsTag.java?view=markup
>
> I'll put most of this text in the Struts Wiki at
> http://wiki.apache.org/struts/ActionErrorsAndActionMessages Anyone
> who wants to clarify is encouraged to document it there, and, of
> course, if you see a place in the core struts docs that could make
> this more clear, we welcome documentation contributions as much as
> code contributions.
>
> Joe
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
> back; I'll know I'm in the wrong place."
> - Carlos Santana
>
> ---------------------------------------------------------------------
> 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]
