[ic] Comparing form fields

[Ethan Rowe]

Jamie Neil wrote:

> Can anyone suggest a way that I can compare two submitted form fields 
> to see if they match and then set mv_nextpage according to the result? 
> I'm asking the user to type in a password and confirmation and I want 
> to return to the same page with an error if they don't match.
>
I just barely went through the delight of figuring this out.  You can do 
it with a form profile to get the error message you want, somewhat 
inelegantly.  You an [if] to compare the two variables; for instance, 
the following uses an explicit type if to strip off leading and trailing 
whitespace, then matches them.  You could do a standard [if] with no 
perl to compare them, but they really have to be an exact match to work.

I did the following (in a form profile):

        [if type=explicit compare=`
             my %vals = ( 'email' => $CGI->{email} || '', 'email_verify' 
=> $CGI->{email_verify} || '' );
             do { $vals{$_} =~ s/^\s+//; $vals{$_} =~ s/\s+$//; 
$vals{$_} = lc( $vals{$_} ); } for ('email', 'email_verify');
             return 1 unless $vals{email} eq $vals{email_verify};
             return 0;
         `]
             always_empty=required The email address and email 
verification fields do not match.  Please verify your email address 
before proceeding.
         [/if]

How this works:
    - the [if]...[/if] is interpolated at the beginning of profile 
processing (I think).  If the [if] evaluates to true at that point, the 
enclosed block (in this case, the always_empty=required stuff) 
effectively becomes just another term in the profile.  This means that 
your [if] should not depend on any values you might manipulate within 
the form profile (via the &set pragma, for instance), because you'll get 
unpredictable behavior.
    - the profile is evaluated, and my "always_empty" parameter is 
checked; I made sure there is no CGI variable of that name submitted, 
and thus that check always generates an error message.  However, if 
you're showing field names with your error messages, showing the name of 
"always_empty" isn't too impressive. :)

This is somewhat lame and I sincerely hope somebody out there can offer 
a better solution.  In any case, I hope it helps.

-- 
Ethan Rowe
End Point Corporation
ethan at endpoint.com