How to convert onSubmit scripts to onBlur?

[John D.]

Many of the available scripts use onSubmit to check fields once a form is submitted. Instead, I would like to be able to check each field as it is used.

Is there a tutorial somewhere that would guide a newbie through the process of making the necessary changes in a script to use onBlur instead of onSubmit?

It's easy with some scripts, but I've found it quite difficult with others, mostly due to the changes necessary in the object, property and/or method references, and my lack of understanding about how they work.

Any help would be greatly appreciated!



BTW, I purchased the book "JavaScript for the World Wide Web," but I have found it to be unclear about how their routines work on their own (they are usually part of larger scripts), and the naming conventions don't seem to be correct from one part of a script to the next. I wouldn't recommend it.

[glenngv]

for me (from a developer's and user's point of view), I prefer to use onsubmit rather than onblur. Using onblur may lead to endless alerts for Netscape, I've experienced it myself.

[requestcode]

It would be better to use onChange than onBlur. You might try the tutorials for this site - http://www.javascriptkit.com . Also try these other sites:

http://hotwired.lycos.com/webmonkey/
http://www.htmlgoodies.com

[glenngv]

onchange is also not good. It will fire the first time you change the value of a field, so you can alert that the input is wrong. If the user just leave the input, the checking will not be triggered anymore.

[whammy]

I also prefer to use onsubmit, since instead of having to write multiple functions (one for every field or whatever), you can have only one function that handles all of the validation, and even returns the user to the field in question (focuses on the field and highlights the bad entry as well).

Not to mention I never did figure out how to use ONE function for multiple fields with the same datatype using onBlur, without causing an endless error loop that makes you have to hit CTRL+ALT+DELETE in order to exit the page (since it won't let you do anything else!), in the case that a field that used the function validation was directly after another similar field (I tried everything I could think of too, with focus() and blur()) :confused:.

No doubt there's something simple that I overlooked, but when I posted here regarding that issue (and I played around with it a LOT before I posted), I don't think anyone answered... :(

[whammy]

One thing though... an ugly solution would be to give each field (at least regarding text fields) a default value that will not be accepted upon form submission (like "Text goes here") :rolleyes:.

In which case even if someone DID leave all of the field values at their default (therefore not triggering the onchange event), the form wouldn't be submitted.

That would solve the problem glenngv is talking about with onchange, but it would uglify your form extremely I think...

[John D.]

Thanks for the input.

The reason I prefer to validate on a field by field basis is because I believe it's easier for the user, particularly in the case of multiple fields that need correction.

To me, onSubmit doesn't offer much difference from server-side validation, but the ability to check each important field as it gets filled out is quite useful.

With what little I've learned so far, onBlur is really the best choice for fields that you require, because if a user just tabs through it, they can trigger an alert.

This looks like the best site I've found for JavaScript support. I'll definitely try the tutorials here. Thanks again to all for the feedback.

[whammy]

I thought the same thing awhile back, but you might be better off using "onsubmit" and returning the focus of the form to the first field that didn't validate, and so on... if a user is trying to enter "real" information, then the difference shouldn't really be a problem anyway - if they are just trying to spoof your form (and you are only using javscript to validate it) they can simply turn off javascript and submit the form anyway, if that's what they're after. :)

I can give you a pretty good example if you want on how to focus on certain fields that don't validate on submit, lemme look through my cd's I have burned if you're interested. :D

P.S. I DO know what your'e trying to acheive, as well, though... if anyone (beetle, jkd, glenngv)? can give an example of how to use the same function(s) over and over again to validate fields onblur without causing the browser to become locked in a loop, I could use the lesson as well!

I have never been able to get that working acceptably.

[glenngv]

The problem with onblur is if the user did not set focus to the field, onblur will not be triggered. So you have to have another validation for each field to double-check the inputs. So there will be duplicate checking.

[John D.]

That would be helpful.

If an onSubmit routine did as you said, first providing an alert that listed all the fields that needed to be corrected, then focusing and selecting the first field that needed correction, then the second field that needed correction, etc., that to me would be a good use of JavaScript and a real advantage over server-side validation routines.:)

[whammy]

Actually, that's fairly easy to do on submit.

I wouldn't discount server-side validation though, since you still want to validate for users that may have javascript disabled for some reason or another, and when using server-side scripting I would prefer to use it to its full advantage, and use BOTH client-side and server-side validation, time allowing...

I have to go to bed soon, but I can give you a pretty good example, I'll try to work it up tomorrow. :)

FYI the idea is as simple as using a global variable... like:

var submitform = true;
function validateform(whatever) {
//yourstuffhere
if(something doesn't validate){
submitform = false;
badfield = "yourfield";
}
if(submitform == false) {
display some message and return focus to the field in question, and returns the function "validateform()" as the boolean value "false" so the form doesn't submit, and eval() the form focus to the field in question...
}


Sorry, that's more of an outline than an actual example, but I don't have a good example handy at the moment. :)

[John D.]

Wow!!

No sooner did you write about scripts turning into an endless loop than I ran right smack into that problem!

I thought I had everything figured out. It took me forever, but I had modifed separate scripts to validate and format zip codes, phone numbers, email addresses and social security numbers. Everything worked fine... at first.

Then all of a sudden I tried it again... and voila... and endless loop of alerts.

I'll post all the code if it helps, but as Whammy said earlier in this thread --

"if anyone (beetle, jkd, glenngv)? can give an example of how to use the same function(s) over and over again to validate fields onblur without causing the browser to become locked in a loop, I could use the lesson as well!"

Anyone?

[glenngv]

if you see beetle's fValidate (http://www.peterbailey.net/fValidate/), you will forget about onblur anymore :D

[John D.]

You're right about that. fvalidate is AMAZING. It addresses all the concerns I had that caused me to think that onBlur was the right approach... WRONG!

I guess onBlur would be fine for a few fields, but for any kind of serious form entry, it looks to me like fvalidate wins hands down. Thanks for the turn-on.

Of course, I'd still like to know if there is a solution to the onBlur endless alert loop problem... just for the sake of curiosity and further education. It sure seems like beetle would know if anyone does. Beetle -- are you around?:cool:

[glenngv]

can you post your code?

[John D.]

Boy, is this proof that I need a life!

I think I found the cause of the endless alerts problem. It appears to happen when two fields that are both being validated by onBlur occur back-to-back.

I tried separating the fields I was validating with fields that I was not validating, and I could not replicate the problem with them separated. When I put them back in a back-to-back order, I was able to replicate the problem once again.

It's probably way too simple or just coincidental, but it might be worth a few other people who have encountered the same issue trying this out and reporting your results.

I suspect that this problem also has something to do with the specific syntax used when passing values to functions and referring to fields within functions, but I don't know JavaScript remotely well enough to re-write the scripts to avoid possible common elements.

I'll gather and post the code in the morning.