Re: Validation functions

This is going to cause a few more problems than it solves.. Imagine doing database code after setting the error handling to numerical.. - it's going to break all your error testing for the database code if you forget to turn error back to object based.. Is there some reason why errors where designed to be passed around rather than stored and requested..? the Validate stuff looks like a perfect place to use something like if (!Validate:number(........)) { $error = PEAR::getLastError(); $errors .= $error->getMessage(); } - it would be nice if all the methods returned TRUE on OK and FALSE on any problem. - it 'makes more sense looking at the code cold.' a simple piece for form validation: foreach( $_POST as $k=>$v) { $method = @$rules[$k]['method']; $args = @$rules[$k]['args']; if (!$method) continue; $r = call_user_func(array('validate',$method),$args) if ($r) continue; // if its ok continue; $errors[$k] = getLastErrorMessage(); } anyway just a few thoughts regards alan Alexander Merz wrote:

So the problem is just, that a user maybe wants to recieve a constant instead of a PEAR_Error object. So what is the problem? What about this: ------------- // set errorhandling to return the errorcode instead of a PEAR_Error PEAR::setErrorHandling( PEAR_ERROR_CONSTANT); if (($res = Validate::number(100, null, null, 1, 10)) < 0) {

         if ($res == VAL_E_OUTOFRANGE)
                 die("Only values between 1 and 10 are allowed");
         else
                 die("You have to submit a number here");

} // now switch to 'normal' handling PEAR::setErrorHandling(); if (PEAR::isError($error = Validate::number(...)) {

    die("Validation failed");

} // or the same like above... PEAR::setErrorHandling(PEAR_ERROR_DIE, "Validation failed"); $error = Validate::number(...) ------------- add to PEAR.php function raiseError(...) {

    ..
    case PEAR_ERROR_CONSTANT :
        ...
        return $error_code ;
    ...

} --------------- So the user gets the full power about error handling.