You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Gary Affonso <gl...@greywether.com> on 2007/11/11 16:56:11 UTC
Is directly setting the Action's fieldErrors map OK?
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Is directly setting the Action's fieldErrors map OK?
Posted by Gary Affonso <gl...@greywether.com>.
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: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Is directly setting the Action's fieldErrors map OK?
Posted by Wes Wannemacher <we...@wantii.com>.
On 11/12/07, Gary Affonso <gl...@greywether.com> wrote:
> Ted Husted wrote:
> > Submit a patch :)
>
> I thought about it. But then I thought that I'm not feeling qualified
> to add generics support to a public API (and a heavily used one, at that).
>
> I'm pretty good at being a *user* of generic classes but I confess that
> creating generic classes/methods intimidates me. I'm thinking the place
> for me to learn is probably not Struts/Xwork's ActionSupport class. :-)
>
> - Gary
Just submitting a patch doesn't mean it will be applied ;)
(Believe me, I submit stuff expecting it to get ignored all the time)
It would at least get eyeballs on the code and the people with the
access to apply the patch will also have the know-how to make sure
that things are done correctly.
-Wes
--
Wesley Wannemacher
President, Head Engineer/Consultant
WanTii, Inc.
http://www.wantii.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Is directly setting the Action's fieldErrors map OK?
Posted by Gary Affonso <gl...@greywether.com>.
Ted Husted wrote:
> Submit a patch :)
I thought about it. But then I thought that I'm not feeling qualified
to add generics support to a public API (and a heavily used one, at that).
I'm pretty good at being a *user* of generic classes but I confess that
creating generic classes/methods intimidates me. I'm thinking the place
for me to learn is probably not Struts/Xwork's ActionSupport class. :-)
- Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Is directly setting the Action's fieldErrors map OK?
Posted by Ted Husted <hu...@apache.org>.
Submit a patch :)
On Nov 11, 2007 1:14 PM, Gary Affonso <gl...@greywether.com> wrote:
> Now, if only the internal FieldErrors map was genericised. One of two
> isn't bad, though. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Is directly setting the Action's fieldErrors map OK?
Posted by Gary Affonso <gl...@greywether.com>.
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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org