Re: Weirdness/possible bug in Validator dependencies
Hallo (David)
I just looked at the code and it looks like I broke
backwards compatibility when I added the methods that
return objects instead of boolean values. The
validateDate method used to default to true and only
validate the field if it wasn't blank or null. So if
the field was blank, date validation was skipped but
'true' was returned so an error message wasn't
generated. Now the method returns null which is being
interpretted as a failure so an error message is being
created. We might need to remove this functionality
for now and just use the boolean methods at least
until after the Struts 1.1 release. I'll think if
there are any other ways to do this and keep it
backwards compatible.
Please don't do that :-) Let the functions return objects.
Just return null in case nothing is entered in the input field.
The validator date should not depends on required at that case.
I think, that it would be not bad to remove this required dependency
for other types as well, so user can have an option to enter
non-obligatory field, but if it does so, then the field will be checked.
Let me know your opinion about it.
The problem pointed out by James problem can be easily fixed if the block
in StrutsValidator.validateDate
if (result == null) {
errors.add(field.getKey(), StrutsValidatorUtil.getActionError(request,
va, field));
}
would be moved into
if (!GenericValidator.isBlankOrNull(value)) {
}
block.
Greetings,
Dmitri Valdin
--
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn
Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das
unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorized copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Weirdness/possible bug in Validator dependencies
The Validator was designed to work this way so there could different groupings of validation rules. Because some times it may not make sense to continue with certain validations until the form is in a certain state. The depends attribute in the pluggable validator definitions is what controls these groupings. So to have validation performed on everything at the same time, the depends attribute can be either zero length or removed. validator name=mask classname=org.apache.struts.util.StrutsValidator method=validateMask methodParams=java.lang.Object, org.apache.commons.validator.ValidatorAction, org.apache.commons.validator.Field, org.apache.struts.action.ActionErrors, javax.servlet.http.HttpServletRequest depends=required msg=errors.invalid David --- James Turner [EMAIL PROTECTED] wrote: Let's say I have two validations: field property=gender depends=required arg0 key=subscriberForm.gender.label/ /field field property=dateOfBirth depends=required,date arg0 key=subscriberForm.dateOfBirth.label/ /field Now, on the form, I leave gender blank and put garbage in for dateOfBirth. When the form validates, gender is given an error because it is blank, and dateOfBirth is not flagged at all. Why? Because in org.apache.commons.validator.Validator.validate(), hActionsRun is defined outside of the main loop. This means that if any field fails the required test, dateOfBirth will never run the date check because the required dependency fails, even though it's for another field. If you then put an entry in gender, required passes, and on the next form submission, you finally get your error for dateOfBirth. If hActionsRun were moved inside the loop, it would work correctly. However, it would mean that one field couldn't have a dependency that was defined by another, which I think is OK, since that's not supposed to be kosher as far as I can tell. Should I submit that as a patch against commons? James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Weirdness/possible bug in Validator dependencies
At 03:57 PM 7/15/2002, David Winterfeldt wrote:
The Validator was designed to work this way so there
could different groupings of validation rules.
Because some times it may not make sense to continue
with certain validations until the form is in a
certain state. The depends attribute in the pluggable
validator definitions is what controls these
groupings. So to have validation performed on
everything at the same time, the depends attribute can
be either zero length or removed.
But if I remove the remove depends from the validation.xml and
set up my date of birth rule to say:
field
property=dateOfBirth
depends=required,minlength,date
arg0 key=subscriberForm.dateOfBirth.label/
arg1 name=minlength key=${var:minlength} resource=false/
var
var-nameminlength/var-name
var-value10/var-value
/var
/field
If I put in a blank entry for it (all other fields filled out), I get:
Date of Birth is not a date.
Date of Birth is required.
(I would expect only the required message, since it comes first in the list.
If I fill it out with 08/0A, I get:
Date of Birth is not a date.
Date of Birth can not be less than 10 characters.
(I would expect only the is not a date message)
If I fill it out with 08/02/62, I get
Date of Birth can not be less than 10 characters.
Which is what I expect.
I'm going to put it bluntly. For every reasonable expectation I could
make about how
validations should work with depends, it does something different and
incompatible
with the way people code validations on forms in commercial environments
dealing
with end users.
James
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Weirdness/possible bug in Validator dependencies
I just looked at the code and it looks like I broke
backwards compatibility when I added the methods that
return objects instead of boolean values. The
validateDate method used to default to true and only
validate the field if it wasn't blank or null. So if
the field was blank, date validation was skipped but
'true' was returned so an error message wasn't
generated. Now the method returns null which is being
interpretted as a failure so an error message is being
created. We might need to remove this functionality
for now and just use the boolean methods at least
until after the Struts 1.1 release. I'll think if
there are any other ways to do this and keep it
backwards compatible.
David
--- James Turner [EMAIL PROTECTED] wrote:
At 03:57 PM 7/15/2002, David Winterfeldt wrote:
The Validator was designed to work this way so
there
could different groupings of validation rules.
Because some times it may not make sense to
continue
with certain validations until the form is in a
certain state. The depends attribute in the
pluggable
validator definitions is what controls these
groupings. So to have validation performed on
everything at the same time, the depends attribute
can
be either zero length or removed.
But if I remove the remove depends from the
validation.xml and
set up my date of birth rule to say:
field
property=dateOfBirth
depends=required,minlength,date
arg0 key=subscriberForm.dateOfBirth.label/
arg1 name=minlength key=${var:minlength}
resource=false/
var
var-nameminlength/var-name
var-value10/var-value
/var
/field
If I put in a blank entry for it (all other fields
filled out), I get:
Date of Birth is not a date.
Date of Birth is required.
(I would expect only the required message, since
it comes first in the list.
If I fill it out with 08/0A, I get:
Date of Birth is not a date.
Date of Birth can not be less than 10 characters.
(I would expect only the is not a date message)
If I fill it out with 08/02/62, I get
Date of Birth can not be less than 10 characters.
Which is what I expect.
I'm going to put it bluntly. For every reasonable
expectation I could
make about how
validations should work with depends, it does
something different and
incompatible
with the way people code validations on forms in
commercial environments
dealing
with end users.
James
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Weirdness/possible bug in Validator dependencies
At 06:08 PM 7/15/2002, you wrote:
I just looked at the code and it looks like I broke
backwards compatibility when I added the methods that
return objects instead of boolean values. The
validateDate method used to default to true and only
validate the field if it wasn't blank or null. So if
the field was blank, date validation was skipped but
'true' was returned so an error message wasn't
generated. Now the method returns null which is being
interpretted as a failure so an error message is being
created. We might need to remove this functionality
for now and just use the boolean methods at least
until after the Struts 1.1 release. I'll think if
there are any other ways to do this and keep it
backwards compatible.
I'd strongly recommend this get fixed BEFORE 1.1 is released.
For those of us trying to use, develop with, deploy with, or
write about Struts, we need 1.1 to be as strong a release
as possible. As is, I'm going to have to recommend to
my readers that they give validator a pass in 1.1 and
wait for further development, because it isn't robust enough.
PLEASE consider taking another look at the refactor I did,
it handles things like this correctly, in that if you say
required, date, it will never even get to the date check
if the required test fails. I think that the behavior you're
trying to protect (grouping errors messages) is in fact
the opposite of what the industry does. I'll quote my
co-author in a letter to me:
1. I'm behind you on this - best to annoy the user all
at once rather than incrementally. I've seen this
problem with Javascript validation on multiple fields
as well - you get one javascript pop-up at a time as
the form is pre-processed prior to the Post occuring.
James
David
--- James Turner [EMAIL PROTECTED] wrote:
At 03:57 PM 7/15/2002, David Winterfeldt wrote:
The Validator was designed to work this way so
there
could different groupings of validation rules.
Because some times it may not make sense to
continue
with certain validations until the form is in a
certain state. The depends attribute in the
pluggable
validator definitions is what controls these
groupings. So to have validation performed on
everything at the same time, the depends attribute
can
be either zero length or removed.
But if I remove the remove depends from the
validation.xml and
set up my date of birth rule to say:
field
property=dateOfBirth
depends=required,minlength,date
arg0 key=subscriberForm.dateOfBirth.label/
arg1 name=minlength key=${var:minlength}
resource=false/
var
var-nameminlength/var-name
var-value10/var-value
/var
/field
If I put in a blank entry for it (all other fields
filled out), I get:
Date of Birth is not a date.
Date of Birth is required.
(I would expect only the required message, since
it comes first in the list.
If I fill it out with 08/0A, I get:
Date of Birth is not a date.
Date of Birth can not be less than 10 characters.
(I would expect only the is not a date message)
If I fill it out with 08/02/62, I get
Date of Birth can not be less than 10 characters.
Which is what I expect.
I'm going to put it bluntly. For every reasonable
expectation I could
make about how
validations should work with depends, it does
something different and
incompatible
with the way people code validations on forms in
commercial environments
dealing
with end users.
James
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Weirdness/possible bug in Validator dependencies
Just took a second thought at this, and realized that you're right in the sense that even with my code in place, you need to make them boolean because otherwise optional dates would fail validation (and optional credit cards, and any other typed value) +1 to backing back out to booleans. There is no other way to indicate that a blank value is OK. James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Weirdness/possible bug in Validator dependencies
Let's say I have two validations: field property=gender depends=required arg0 key=subscriberForm.gender.label/ /field field property=dateOfBirth depends=required,date arg0 key=subscriberForm.dateOfBirth.label/ /field Now, on the form, I leave gender blank and put garbage in for dateOfBirth. When the form validates, gender is given an error because it is blank, and dateOfBirth is not flagged at all. Why? Because in org.apache.commons.validator.Validator.validate(), hActionsRun is defined outside of the main loop. This means that if any field fails the required test, dateOfBirth will never run the date check because the required dependency fails, even though it's for another field. If you then put an entry in gender, required passes, and on the next form submission, you finally get your error for dateOfBirth. If hActionsRun were moved inside the loop, it would work correctly. However, it would mean that one field couldn't have a dependency that was defined by another, which I think is OK, since that's not supposed to be kosher as far as I can tell. Should I submit that as a patch against commons? James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
