Welcome to WebmasterWorld Guest from

Forum Moderators: open

Message Too Old, No Replies

A Universal Script for Javascript Form Validation

I'm finally getting around to writing a universal script



2:01 pm on Sep 21, 2008 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member

This is something I've been conceiving for quite a while now, a universal script to validate any form fields.

The types I've got planned so far are:
Free text
Letters (including space but no symbols)
Both (like an address line)
Phone number
An email address
Dates (various formats)
Custom field (like a reference number, you'll be able to specify a character sequence)

Any other common things I've missed?

Other features will include, case transformation, phone number formatting, date validity, popup calendar, default text, force required fields, active/disable by checkbox/select....and finally, parent CSS class changing.

I'd also like any ideas and feedback you guys can think of to throw into this, of course it will be freely available for use and scrutinization when it's workable!

[edited by: Dabrowski at 2:02 pm (utc) on Sep. 21, 2008]


11:31 am on Oct 12, 2008 (gmt 0)

5+ Year Member

We generate the "validation hints" for the library we use from definitions that are held [i.e. specific to the Form] server-side, and thus those same "validation definitions" are also available server-side.

I have found it very difficult to do EMail validation client-side - the RFC is hugely complex, and trying to constrain to .CO.xx and .#*$! that are allowed CURRENTLY is a moving target :(

So we do some basic checks client-side (exactly one "@" and so on) and then do an MX lookup server-side, which seems to be a pretty good compromise (can still have a Name @ the Domain that isn't valid, but some Domains even validate that in the MX lookup)

@ Fotiman:

One thing about "clean markup" and putting the "configuration data" separately in a class is that two are a long way apart in the source code, which IME introduces errors. Hence my preference for a system that includes the validation-hints in the INPUT statement


1:38 pm on Oct 12, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member

I use to implement javascript form validation routines. They are just not reliable any more with so many different ways folks are accessing our site. Many mobile devices do not support JS yet, or it is optional, etc. Many folks run script blockers for security reasons.

In my opinion, server-side validation is the only way to go. Consistency is the key. Unless you are going to use javascript validation for everything on your site, why use it for forms?


2:00 pm on Oct 12, 2008 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member


Yes mate, that's looking remarkably similar to the structure I have, apart from the actual config parts.


Thanks for the suggestions. Number ranges are something that I had already planned for, but dates ranges and past/future would also be very handy.

callbacks will be implemented, as per Krispy2's suggestion earlier in the thread.

For each element, onbeforevalidate, onaftervalidate.
For each form, onbeforesubmit.

So to check for your unique user, you'd use onaftervalidate for the element -- which would fire on successful validation. That way you know the, for example, username your function is checking is actually valid first. Then your fuction could set the elements validate ok flag false.


As vvv said:

I think you really should consider building this to be driven server side

I absolutely agree, for critical data input, JS alone cannot be relied upon. However, your server side script can easily insert the code for the JS validator on the page. That way you are only doing the work once! ;)


I have found it very difficult to do EMail validation client-side

I have been considering this. Currently I check for valid format, e.g. something@somewhere.somedomain, which is the minimum.

I thought of including a list of all TLD's in the script, to at least check that, but it's really pointless. You can't check the domain in valid with JS, and even if it is you can't check the username is valid.

I think all I can do is validate the format, then you could use a callback function to check the DNS if you require.


In my opinion, server-side validation is the only way to go

Certainly not the only way, but still absolutely necessary yes.

Unless you are going to use javascript validation for everything on your site, why use it for forms?

Why not se Javascript for everything? With the advent of AJAX, and even as far back as DOM scripting, javascript can be used to greatly enhance the user experience where available.

With a JS form validation, you can highlight errors before the user tries to submitthe form. I've used sites where you hit submit, it complains that you've made a typo somewhere, but DOESN'T pre-fill the form in. So I have to fill the whole damn thing out again cos I filled in a date wrong.

Right, I'm off on holiday now for 10 days, so I'll pick this up again when I get back....unless I get bored!



2:00 pm on Oct 12, 2008 (gmt 0)

5+ Year Member

We use JavaScript, client-side, so that the user gets faster feedback when they enter inappropriate data - i.e. the moment that a form-field loses focus - whilst it is still fresh in their memory, and they can easily fix the data.

If we only validate server-side, after the form is completed, we find that users are confused as to what they are supposed to do - the big red validation message is somehow invisible to some users :( and doing real-time field validation, server-side, is unnecessarily demanding on our servers. But we still need the sever-side validation, of course, for anyone who Submits data without having had the client-side validation.


5:04 pm on Oct 12, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month

--a universal script to validate any form fields --

I think the client-side script should mimic the the server-side language functionality/syntax. This way when Webmaster is finaly ready to dive into Dev Work he/her is somewhat familiar with the situation.

But then again, vincevincevince described exactly what CFForm and CFInput functionality does in ColdFusion8, including call-backs via Ajax, Regex, Ranges and CAPTCHA ;).

I agree with Krispy2 on 'Faster Feedback' point, but there is absolutely a must serverside validation for any data that would stored in DB, Flat files, ...just stored...

just mt 2 bites..



7:49 pm on Oct 12, 2008 (gmt 0)

5+ Year Member

I personally use my own server side subroutines. The function will do a full server side validation as well as outputting the required javascript routines for the form which has slight changes depending on the user-agent.


8:50 am on Oct 13, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member


why would I want to check it client-side with all possible side effects like javascript disabled and then check it again server-side? Want a field one char longer? "Simply" change the rules server-side AND client side!

Another reason to only perform server side checking (at least for me): I don't neccessarily want "evil" visitors to know about my rules. When using javascript the rules are open for everybody to read. Server side I can simply refuse an entry without giving a specific reason.


12:26 pm on Oct 13, 2008 (gmt 0)

5+ Year Member

"why would I want to check it client-side"

IMHO kindness to the user - i.e. more friendly / faster experience for users with JavaScript enabled.

""Simply" change the rules server-side AND client side!"

In my case I "define" the rule centrally (server-side) and that rule is used by the server-side validation, and the server generates the code for the client-side validation** - thus I only change once. I agree that if it is necessary to change it in two places its an accident/bug-waiting-to-happen.

That aside, we have plenty of server-side-only rules - such as referential integrity checks, and "someone else edited it already, sorry"

** actually the code generated isn't case-by-case-specific, it just applies validation-categories, such as "integer" or "integer between THIS and THAT" and "required", and the validation library applies those "categories"

"I don't neccessarily want "evil" visitors to know about my rules"

True, and I am conscious of what we "expose" in that way. Its hard to guess what might assist a hacker, and maybe even knowing that a specific field has, say, a 10 character limit may be an "advantage" to them. But I don't think that my rather simplistic RegEx for Email validation gives them any advantage (the server-side code is more robust), but it does help the significant numbers (yes, honestly!) of users that type ' instead of @, or forget the ".uk" after ".co" or even just assume that "hotmail" does not also require the ".com" ;)

[edited by: Krispy2 at 12:28 pm (utc) on Oct. 13, 2008]


3:19 am on Oct 14, 2008 (gmt 0)

WebmasterWorld Administrator httpwebwitch is a WebmasterWorld Top Contributor of All Time 10+ Year Member

validation at both client-side and server-side is ideal. Client-side validation improves the user experience, while server-side validation keeps your data pure, prevents SQL injection, XSS etc.

If you can use the same pattern definitions to do both, that's just peachy.

Tip: I find that some fields are OK to validate on blur, some onchange, some only on submit. But there are other kinds of data that are nice to validate onkeyup.


12:32 am on Oct 27, 2008 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member

Right. I'm back. Sadly.

ok, I've overcome my command structure problems...for now, I think I've got most of the options in.

I want to thank you guys for your input, there's some stuff been suggested here that I'd never have thought of!

I have most of the code structure done, I think, and I'm starting to get some workable stuff in. I'll post again when I have something beta for your scrutinization!


6:14 pm on Nov 11, 2008 (gmt 0)

WebmasterWorld Senior Member 5+ Year Member

ok, I have something.

Only a few things are working but building blocks are in place. I have... required, hint, and letters types so far.

Who wants to see?

Code is far too large to post here, so you know what to do.

This 41 message thread spans 2 pages: 41

Featured Threads

Hot Threads This Week

Hot Threads This Month