Comments on: Form Validation Class using PHP 5.3

By: Brett

Brett — Wed, 09 Nov 2011 16:48:27 +0000

The code I posted here is purely for validating form input data. No, it does not protect from SQL injection attacks. The PHP manual has some suggestions for avoiding SQL Injections. Personally, I like to use PDO prepared statements with named place holders. You can use this class to add a callback function or a new inline function to test that your data is valid before actually inserting in your database (which is one of the several purposes of form validation anyway.)

By: Leon

Leon — Wed, 09 Nov 2011 08:17:59 +0000

The validator also protects against sql injections?

By: Ben

Ben — Sat, 29 Jan 2011 15:46:31 +0000

Tasos,

Thanks for the additional rules that you have added to the FormValidator class on github, per my request.

Tasos has added the following rule validations…

startsWith
notstartsWith
endsWith
notendsWith

Thanks again.

By: Tasos Bekos

Tasos Bekos — Mon, 10 Jan 2011 09:45:25 +0000

Hello again Brett.

I have made some changes to your work and published it on github.

I have added rules (basically date validation), moved default error messages into separate function to make it easier for i18n and tried to minimize script warnings.

I implemented the arguments private array in order to leave your caching method untouched.

See: https://github.com/bekos/php-validation and if it’s OK with you you can publish it.

By: Brett

Brett — Thu, 06 Jan 2011 18:54:51 +0000

Thanks Tasos. That was a function caching algorithm I wrote in later. Really not necessary and didn't really save me on resources since I compiled and sent the function anyway. It was working for closures where the use keyword was not in effect because the parameter for the closure was always the current POST value, however, there seems to be no obvious way to determine if the "use" variables were different. I thought about adding a boolean parameter toggle function caching for set_rules() but it just didn't seem feasible (unless I check for the cached function in the public functions themselves, but again little gain for a unnecessary feature.) Thanks again. I will be updating the source code shortly. I might implement the args private array as you suggested later on. For now, feel free to fork the project at github.

By: Brett

Brett — Thu, 06 Jan 2011 14:31:43 +0000

Thanks for the information Tasos.

Can you post an example of how you are validating the fields? Once the validation method is called, the rules array is reset. Not sure why you are having that issue, but then again, I haven’t used this validation class in production much yet.

By: Tasos Bekos

Tasos Bekos — Thu, 06 Jan 2011 09:05:10 +0000

…continue…

I think bug is on line 273 where the new function for the 2nd field is not set because already exists, but with the older aruments.

You can probably remove this check, or better create a private arguments array to be always set and called with validate.

By: Tasos Bekos

Tasos Bekos — Thu, 06 Jan 2011 08:35:49 +0000

Good script but I think there is a bug, about scope.

To reproduce it you can validate 2 different fields for minlength 5 (the 1st) and 2 (the 2nd).
Scope problem validates both fields for minimum length of 5.

Can you confirm this bug?
Thx

By: Brett

Brett — Sat, 01 Jan 2011 20:36:53 +0000

Personally, I prefer not to nag the user about more than one validation failure per field. 1) Because most users are non-technical and it's better to keep instructions simple and 2) users rarely make multiple validation mistakes on the same field. If you require all messages being reported, it shouldn't take too much effort to re-factor the validate() method. Feel free to fork the library at github.

By: moto0000

moto0000 — Thu, 30 Dec 2010 15:37:00 +0000

How to make class pay all the mistakes and not just the first?