For posterity (and to embrace my schizo tendencies by continuing this
conversation with myself)...
It now turns out that setting the FieldErrors via getFieldErrors() may
not be such a good idea after all. Reading the code makes it look OK,
but the API docs for XWork's ActionSupport.getFieldErrors() method
explicitly say...
"Error messages should not be added directly here, as implementations
are free to return a new Collection or an Unmodifiable Collection."
Also note that if you're referencing my code from earlier in this
thread, there's a bug. My domain object is returning Map<String,
String> for its validation errors and then doing a "put all" into the
Action's Field Errors.
The problem is that the Action's FieldErrors type (if it had one) isn't
<String, String>, it's <String, List<String>>.
My latest solution is to be a good boy and just loop through my domain
object's errors and add them to the action's errors via the
addFieldError() method...
for (
Map.Entry<String,String> err :
account.getValidationErrors().entrySet()
) {
addFieldError(
validationErrorEntry.getKey(),
validationErrorEntry.getValue()
);
}
Sorry for any confusion.
- Gary
Gary Affonso wrote:
I just checked the source for ActionSupport's addFieldError (which
delegates to ValidationAwareSupport's addFieldError).
It does do a null check on the internal FieldErrors and will initialize
the map before adding a fieldError, if necessary. So, yes, the internal
FieldErrors map can be null.
But!...
getFieldErrors() also does a null check and will initialize the internal
FieldErrors map if necessary (it won't return null). So this should be
fine (no null check required):
getFieldErrors().putAll(account.validate())
I'm thinking this is preferable to just nuking the internal by replacing
it with my own.
Now, if only the internal FieldErrors map was genericised. One of two
isn't bad, though. :-)
- Gary
Gary Affonso wrote:
I've got two questions, here's the summary:
I'm doing validation in my domain objects. They kick back a map..
public class DomainObject {
public Map<String, String> validate() {...}
}
In my action's validate method, I just delegate to the domain object's
validate() method. Something like this...
public void validate() {
// Delegate validation
Map<String, String> errs = new LinkedHashMap<String, String>();
errs.putAll(account.validate());
errs.putAll(postalAddress.validate());
setFieldErrors(errs);
}
Here's my question...
As you can see from the above, when I get my errs Map back from my
domain object (it will always be non-null) I've just been replacing
the Action's field error map with my own...
setFieldErrors(errs);
It's working now but it seems like blasting the existing Action's
internal fieldErrors map with my own seems to be asking for trouble.
This option is compelling...
public void validate() {
getFieldErrors().putAll(account.validate())
getFieldErrors().putAll(postalAddress.validate())
}
But I have two problems with that. It assumes the internal
fieldErrors map will never be null (is that true?) and it also emits a
warning (in Eclipse) because the the internal FieldErrors map has not
be genericized (and my domain objects Map has). I could code around
both of those, of course, but then it's verbose enough to be not so
compelling anymore.
Another option is to loop over error map generated by my domain object
and then add each of those to the Action's FieldError map via
addFieldError(). That seems the safest, presumably the addFieldError
method is doing null checks, new map setup if necessary, etc. But,
dang, that's a lot of code just to transfer some strings around.
Comments?
- Gary
P.S. My Action is extending ActionSupport, this is how I'm ensuring
that the Acition knows about things like FieldErrors.
---------------------------------------------------------------------
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]
