Hi,
Imagine the situation where you have a form with password and password_confirm fields and you want to make sure the values match. Now, in the Zend_Filter_Input validation array you can either put the StringEquals validator under the password field or the password_confirm field.

If you put it under the password field--and because you then have to specify the FIELDS metacommand--other validators, such as StringLength, don't work any more, I think this is because they don't know how to deal with the multiple fields? Is this a bug? Here is my code:

'password' => array(
   new Zend_Validate_StringLength(6),
   new Zend_Validate_StringEquals(),
   'fields' => array('password', 'password_confirm'),
),

The Zend_Validate_StringLength always returns false, not matter what I enter.

Alternatively, you can specify the StringEquals validator under the password_confirm field. Now this (in my mind) makes a lot more sense, as it is only relevant if that field exists, and it solves the above problem. However, it introduces one as well. As the password_confirm field is *only* there for the sake of validation, and the value entered into it will *never* be used, really you don't want it to stay within your Zend_Filter_Input as a valid field. This becomes obvious when you try to do something like:

$user = $users->createRow();
$user->setFromArray($input->getUnescaped());

Because the array returned from getUnescaped will contain the password_confirm field, but the database table does not have this field, an error is thrown. Now I know this is very easy to get around, but I think it would be benefical to have a new metacomand called DISCARD (or something similar), which basically tells Zend_Filter_Input to discard the value rather than saving it, once validated.

What to other people think?
Thanks,
--
Jack

Reply via email to