[ic] Email and &and profile check

[Peter]

On 09/26/2008 01:32 PM, Mike Heins wrote:
> 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.

The $And variable tells you if you're on an and check or an or check. 
If you're on an and check and the previous check failed then you can 
skip this check.  If you're on an or check and the previous check 
succeeded then you can skip.  In both of the above cases it's not 
necessary to perform this check.  I don't see how we need to be 
concerned with any other types of logical grouping.

> 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.

You skip the check if you've just encountered an &and line (as indicated 
by the $And variable) and the previous check failed (or vice versa for 
an &or).

We would need to account separately for the format of having the check 
on the same line as the &and or &or, though.

>>>> 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.

I tend to agree but that is how it is.  I would want to make absolutely 
certain that making any such change doesn't break anything (I get the 
feeling it would break lots of existing code for displaying the error 
message in form fields).

Peter