CodeStore.net comments on "Simple OO JavaScript Form Validation"

Reply from Paul

Paul — Fri, 17 Oct 2008 09:07:34 -0500

Great article! I'll just have to say that if you are writing to a database, both server and client-side validation are essential. Server side is not necessarily for the user's benefit, but for the "cleanliness" of the data. I am not interested in providing a nice response to users who choose to circumvent client side validation so checking on the server is for me, strictly to prevent anything malicious from being written to the database.

Reply from zack Smith

zack Smith — Mon, 2 Jul 2007 01:47:00 +0100

man thanks for writing this... you do make it seem simple!

Reply from Jerry Carter

Jerry Carter — Fri, 26 May 2006 17:48:00 +0100

I agree with MoGryph. OO Js not only isn't that hard, as Jake has found, once you get into it, and reusable (code once use often), Client side JS is a courtesy to the user. Would you rather wait for a form to submit and then get a page returned to you with modifications or some other alert telling you where the error are (most shopping forms online come to mind) or would you rather know about input miistakes as each field is completed?

There are some great arguments for making the UI nicer, especially where not frustrating the user could be the difference between a new customer and lost business.

I do agree with GM though that you do need server side validation for the stated reason that you can get 'round JS validation if you want to.

I think this conversation has happened already in the past here on Codestore... the gist being do both. Client for the customer, server for the data.

Reply from MoGryph

MoGryph — Fri, 26 May 2006 14:56:00 +0100

Oh yeah, and here are a couple of great links for learning some more fine and amazing nitty-gritty points of JavaScript OO.

Inheritance: link

Private/Priveleged methods:

Link

The guy's got a page with a bunch of links for Javascript, here:

{Link}

Lots of advanced stuff.

Reply from MoGryph

MoGryph — Fri, 26 May 2006 14:23:00 +0100

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.

Reply from GM

GM — Fri, 26 May 2006 08:12:00 +0100

For form validation I don't see the need for something like a "Validator" object - it seems to be a waste of time and energy to go through so much trouble to validate a form on the client side, when the user can freely circumnavigate this code. On the server-side, however, I can understand it fully, although there you wouldn't be using Javascript, obviously. On the client side, a basic "Is the field empty?", "Is the field a number?", "Is the value within this range?" type of validation is usually sufficient.

I think Javascript objects are much more useful and relevent in creating DHTML elements - I use JS objects for sortable tables, collapsable sections, appearing/disappearing areas etc. and there I find JS objects almost indispensable.

Reply from Rich Waters

Rich Waters — Thu, 25 May 2006 08:37:00 +0100

OO Javascript is really easy once you get the hang of it, once you get the basics down I really reccomend taking a look over at prototype and all the functionality it can add to OO javascript. I saw you post about a validation routine based on prototype the other day, which is very similar to mine, though I prefer my coding style (who doesn't prefer their own :). Here's the first article I wrote about the validation {Link} and here's the SnTT I wrote on how to add it into a domino form {Link}

I tried to keep it very simple to expand on so that custom validation routines would be simple to add. Hope someone finds it helpful.

Reply from Jerry Carter

Jerry Carter — Thu, 25 May 2006 07:10:00 +0100

Of course there are benefits. I mentioned adding a widget more than once to a form a couple of days ago. So to extend the example, you could create a couple of objects, say FormValidator and ValidatorRule. Your FormValidatorInit could receive a string array of fieldnames, and maybe RegEx pattern pairs, with which it would create a chiled collection or array of ValidatorRule objects. FormValidator.isValid would be called from your onsubmit and would simply need to query each Validator.Rule.isValid method to see if FormValidator.isValid returns true or false.

That's the rough workflow. The object topography would of course be a bit more detailed, but you get the idea. Now I can init FormValidator with multiple fields (or other things), each of which simply becomes a ValidatorRule, which can contain all the methods I need for each items validation logic based on how it was initialized by FormValidator.

Very useful when I don't have to unravel miles of conditional logic, or rewrite said lagic, everytime I add a field.