[ic] Email and &and profile check

[Mike Heins]

Quoting Stefan Hornburg (Racke) (racke at linuxia.de):
> Peter wrote:
> > On 09/25/2008 08:02 AM, Mike Heins wrote:
> >> Quoting Stefan Hornburg (Racke) (racke at linuxia.de):
> >>> Hello, 
> >>>
> >>> the &and is kind of counterintuitive when it comes to check the same variable multiple times:
> >>>
> >>> email=email_only Please enter a valid email address.
> >>> &and
> >>> email=match email_verify Emails you entered do not match.
> >>> &and
> >>> email=unique userdb:email Unfortunately, an account with this email address already exists.
> >>>
> >>> So if fail to enter an email address at all, I see all three error messages at once.
> >>>
> >>> Isn't that confusing?
> > 
> > Perhaps, but I think the point is to tell the user all the errors at 
> > once as opposed to making them fix one error before telling them the 
> > next one (thereby resulting in them having to continuously refresh the 
> > page time after time until they get all the errors fixed).  I would not 
> > be in favor of changing this behavior unless there is some way to 
> > control it and the default is the current behavior.
> 
> That's right, but in this specific case it is meaningless to check whether
> emails are matching when the first field is empty.
> 
> > 
> >> If we can determine the bounds of the entire expression, and can determine
> >> if it is an &and, then we probably should not perform tests 2 and 3. I am
> >> not sure that state machine is sophisticated enough to do that, but it
> >> is in the check_order routine of Vend::Order, or more precisely &chain_checks.
> >>
> >> I can see right now the problem is that we have no real way to bound
> >> the expression. So probably for right now, there is no solution
> > 
> > I don't think it's needed to determine the bounds of the entire 
> > expression.  Since it is evaluated top to bottom anyways, all we need to 
> > know is if we can skip the current expression or not based on what the 
> > previous expression evaluated to.  We would do this in the check_order 
> > sub, actually, around line 1054 or so, and all the info needed is 
> > available there already.

Have you considered the effect of &or, and other types of logical
grouping? I suppose you could set a flag when you do an "and", and
not do the second check if the variable name is the same. But that
seems convoluted.

And what is the behavior if one condition of an &and fails? Do we just
skip the *next* check, and then only skip again if &and is again
encountered? That is what I meant by bounding.

> > 
> >> short
> >> of enhancing the error tag to allow display of only the first error.
> > 
> > I don't think that would be possible as the error messages get catted 
> > together in one message separated by " and " (around line 1085).
> 
> That's really messy and a good candidate to add this to my blog entry
> http://blog.linuxia.de/flaw_in_interchanges_error_model
> 
> It would make much more sense to use an array here and concatenate it
> together within [error] later.

Yup.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.328.4479  tollfree 800-949-1889 <mike at perusion.com>

Being against torture ought to be sort of a bipartisan thing.
-- Karl Lehenbauer