homepage Welcome to WebmasterWorld Guest from 54.205.52.110
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / JavaScript and AJAX
Forum Library, Charter, Moderator: open

JavaScript and AJAX Forum

This 41 message thread spans 2 pages: < < 41 ( 1 [2]     
A Universal Script for Javascript Form Validation
I'm finally getting around to writing a universal script
Dabrowski




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

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)
Numbers
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]

 

Krispy2




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

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

maximillianos




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

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?

Dabrowski




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

@fotiman...

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

@vincevincevince...

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.

@jcaron...

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! ;)

@krispy2...

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.

@maximillianos...

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!

ciao!

Krispy2




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

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.

blend27




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

--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..

blend27

Seb7




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

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.

the_nerd




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

jcaron,

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.

Krispy2




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

"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]

httpwebwitch




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

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.

Dabrowski




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

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!

Dabrowski




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

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 ( 1 [2]
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / JavaScript and AJAX
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved