Re: Weirdness/possible bug in Validator dependencies

[Dimitri Valdin]

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:   
For additional commands, e-mail: 

Re: Weirdness/possible bug in Validator dependencies

[James Turner]

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:   
For additional commands, e-mail: 

Re: Weirdness/possible bug in Validator dependencies

[James Turner]

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:
> >
> >  >   property="dateOfBirth"
> >   depends="required,minlength,date">
> >   
> >> resource="false"/>
> >   
> > minlength
> > 10
> >  
> >  
> >
> > 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:
> > 
> > For additional commands, e-mail:
> > 
> >
>
>
>__
>Do You Yahoo!?
>Yahoo! Autos - Get free new car price quotes
>http://autos.yahoo.com
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Weirdness/possible bug in Validator dependencies

[David Winterfeldt]

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:
> 
>property="dateOfBirth"
>   depends="required,minlength,date">
>   
>resource="false"/>
>   
> minlength
> 10
>  
>  
> 
> 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:  
> 
> For additional commands, e-mail:
> 
> 


__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Weirdness/possible bug in Validator dependencies

[James Turner]

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:


  
  
  
minlength
10
 
 

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:   
For additional commands, e-mail: 

Re: Weirdness/possible bug in Validator dependencies

[David Winterfeldt]

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.




David

--- James Turner <[EMAIL PROTECTED]> wrote:
> Let's say I have two validations:
>property="gender"
>   depends="required">
>   
>  
>property="dateOfBirth"
>   depends="required,date">
>   
>  
> 
> 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:  
> 
> For additional commands, e-mail:
> 
> 


__
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: