GM- I tend to disagree- the less traffic you have going back and forth to/from a server, the better. I don't see any reason for not validating again on the server side (in case you believe that you've got those sneaky users circumventing the system), but if you can reduce the extra baggage for the simple users, all the better. Back/forth communication doesn't just reduce server response time, but can really irritate end-users if things are slow. Most end-users would prefer to have an immidiate message telling them they've missed something, rather than- Submit.... wait... dang, I messed up- fix it, submit... wait.... Ah... finally. If they never have to say "Ah... finally" because of multiple slow submits, then we've done our job correctly.
I've used OO JS Objects for validation before, only in a different manner.
I've got a few databases out there, where the best way I was able to build them, meant that they needed Computed subforms. Yeah, yeah, I know they're supposed to slow stuff down, but it was the only way I could think of doing some of the things I was trying to accomplish.
The headache showed up, when I was trying to figure out the best way to validate fields, regardless of which subform(s) were added to the form, without building one huge bloated JS file that 90% of which might never have been used by most of the users.
What I ended up doing, was creating a global JS Validator object that contained an empty collection variable, and a function to add new Validation functions to the collection.
At the top of each of the subforms that might be added, I had a custom validation function, and used Validator.addValidation(thisFunction). Thinking back, it probably would have been better to have each of the functions imported from their own separate .js files. Ah... Hindsight.
Then, in my OnSubmit, I just called Validator.validate(), which enumerated all the functions in the container object, collected comments for each validation that failed (they returned a message on failure, and "" on success) and alerted a single message for all errors. It kept things nice and nice and clean and dynamic.
GM- I tend to disagree- the less traffic you have going back and forth to/from a server, the better. I don't see any reason for not validating again on the server side (in case you believe that you've got those sneaky users circumventing the system), but if you can reduce the extra baggage for the simple users, all the better. Back/forth communication doesn't just reduce server response time, but can really irritate end-users if things are slow. Most end-users would prefer to have an immidiate message telling them they've missed something, rather than- Submit.... wait... dang, I messed up- fix it, submit... wait.... Ah... finally. If they never have to say "Ah... finally" because of multiple slow submits, then we've done our job correctly.
I've used OO JS Objects for validation before, only in a different manner.
I've got a few databases out there, where the best way I was able to build them, meant that they needed Computed subforms. Yeah, yeah, I know they're supposed to slow stuff down, but it was the only way I could think of doing some of the things I was trying to accomplish.
The headache showed up, when I was trying to figure out the best way to validate fields, regardless of which subform(s) were added to the form, without building one huge bloated JS file that 90% of which might never have been used by most of the users.
What I ended up doing, was creating a global JS Validator object that contained an empty collection variable, and a function to add new Validation functions to the collection.
At the top of each of the subforms that might be added, I had a custom validation function, and used Validator.addValidation(thisFunction). Thinking back, it probably would have been better to have each of the functions imported from their own separate .js files. Ah... Hindsight.
Then, in my OnSubmit, I just called Validator.validate(), which enumerated all the functions in the container object, collected comments for each validation that failed (they returned a message on failure, and "" on success) and alerted a single message for all errors. It kept things nice and nice and clean and dynamic.