views:

90

answers:

3

For my framework I've written down this concept to solve the form validation problem. I want it to be as straightforward as possible for the framework user.

Every Form (=object) has one or many FormElements (=objects). Every FormElement can have 0-n FormValidators (=objects). Everything easily configured through the backend (simple drag&drop stuff).

When the Form View is rendered, it loops over all the FormElements, and for each of them it loops over all their associated FormValidators. That way it builds up all the needed JavaScript to validate the form on client side.

A FormValidator is an lightweight object which defines only these seven things:

  • PHP class name of the validation utility class
  • method name of the validation utility class, which must be called
  • a string for additional arguments (comma-separated values)

  • JavaScript "class" name of the validation utility

  • "method" name which must be called
  • a tring for additional arguments (comma-separated values)

  • an associated ErrorInfo object which contains an formatted error message

Every of these validation methods takes as first argument an input variable with the input data. Every of these methods just check the input if it matches some rule(s), and returns TRUE or FALSE.

When the form is submitted, an FormDataManager is created and receives: - the Form object (so it knows from where the data came from) - the input data (typically $_POST)

It then just iterates over all the FormElements, checks all their FormValidators, and if anything is invalid, it reloads the Form which is passed the error messages array. If everything is fine, the data is further processed (i.e. stored to db).

Are there improvements in this design? Anything I've missed?

+3  A: 

One common validation concept which I think you have missed is validation groups. For instance, you may want to cater for one of the following scenarios:

  • Form field B is mandatory only if field A has any value.
  • Form field B is mandatory only if field A has a specific value.
  • Form field B is mandatory only if field A is in a specific range (numerical or dates).
  • Either field A OR field B needs to have a value (they cannot both be empty).
  • Either field A OR field B needs to have a value (they cannot both be empty or both have a value) - (XOR).
  • Password and confirm password fields need to be equal.

And I'm sure there are other scenarios where validation depends on the validity or optional aspect of other form elements. Also - 'mandatory' in the scenarios above may also be simply 'applicable', which would be a different situation again. Typical (medical system) example here is: "Are you male/female?", with a follow-up of "Are you pregnant?" for females. Or AOP related questions, where you have the birthday and have a certain follow-up question only IF they are 65 years or older.

It means you need some validationgroup or validation association object that contains these dependencies in a useful and generic way.

I guess in your design it means you can also have FormValidator objects that are not directly linked to one FormElement but to a combination of FormElements and include a conditional check before triggering validation.

Wim Hollebrandse
Another typical example would be: Password and Repeat password needs to be same during registration.
Josef Sábl
Thanks Josef - yep very common indeed! Edited.
Wim Hollebrandse
Thanks Wim, I agree with all points. Makes totally sense. I slightly remember Microsoft Outlook or Outlook Express had an similar system with very powerful rules... like "if subject contains FOO or BAR or FOOBAR, and text begins with Hello, delete email". Gotta find out how to do something like this, so generic. Cool stuff!
openfrog
Yes, though the Outlook Express rules were only basic string comparisons with various operators. You're likely going to have regex validation, range validation (for different datatypes) as well as validation for things like checkbox lists (choose at least 3 options) etc. Which makes it far more challenging. Good luck!
Wim Hollebrandse
A: 

Sounds interesting. I think you're on the right track, especially because it sounds like you are validating both client side and server side.

Chris Lively
I see no other option than to validate twice ;) the client side for usability, the server side for security.
openfrog
A: 

One thing that you should do (and I might have missed this when reading your question) is make sure that the validation also happens on the server as well. That way your form information is still validated even if someone turns off or tinkers with the javascript.

Zerodestiny