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-name>minlength</var-name>
> > <var-value>10</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]>
