| This 41 message thread spans 2 pages: < < 41 ( 1  ) || |
I'm finally getting around to writing a universal script
| 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:
Letters (including space but no symbols)
Both (like an address line)
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)|
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)
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)|
| 2:00 pm on Oct 12, 2008 (gmt 0)|
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. email@example.com, 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.
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)|
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)|
--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)|
| 8:50 am on Oct 13, 2008 (gmt 0)|
| 12:26 pm on Oct 13, 2008 (gmt 0)|
"why would I want to check it client-side"
""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)|
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)|
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)|
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  ) |