Re: Validation functions

From: Date: Sun, 23 Jun 2002 13:31:31 +0000
Subject: Re: Validation functions
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-7306@lists.php.net to get a copy of this message
On Sun, 23 Jun 2002, Alan Knowles wrote: > 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(); > } +1 here if you're going to bother catching an error, you have to go through as much hoopla in the current system too; e.g. $error = Validate::number(.....); if (PEAR::isError($error)) { $error = $error->getMessage(); } It's four lines either way, but the adantage of just passing a bool is that an object isn't created every time there's an error, passed and copied several times. This makes more sense to me with validate especially, since a validation function returning a false value is definitely _not_ an exceptional event. You expect it to return false because of the nature of validation. Otherwise, it would be like writing isArray like: function isArray($array) { if (!is_array($array)) { PEAR::raiseError('Not an array!'); } } You see the sillyness? - Brent > - 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. > > > > > > > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >

« previous php.pear.dev (#7306) next »