Yet Another Unobtrusive Form Validation Script

@ jazzle: Thanks for the kind words… always nice to hear!

I’ve actually not looked at the script since the day it was uploaded so might try to work on it this weekend (Safari 2.0.3? has problems with something – which I would like to fix).

It’s just a shame IE5.X doesn’t play fair – then again, IE5.X is fast approaching the realm of “unsupported browsers” for many web applications…

Regards,
Brian

@ jazzle: Is the script throwing errors?

If you mail me a copy of your HTML I shall have a look at it tomorrow.

Update: The problem was that the form tag was nested within the table tag, moving the form tag above the table tag fixed the problem…

Thanks,
Brian

@ Jazzle: Hi Jazzle, in fact, that’s supposed to happen. Optional inputs do not stop the form being submitted even if they are invalid. Required inputs will stop the form submission if they contain invalid data.

I should have made this a bit clearer!

Regards,
Brian.

@ bas: Hi bas, I can’t seem to replicate the problem (using the demo). what browser/platform combo are you using?

Thanks for the comment,
Brian.

@ Chris: Hi Chris, the actual “Effect” is only used within the demo (the callback function “demoCallBack”) and isn’t actually required by the core validation script.

The effect is actually part of the script.aculo.us JavaScript library and can be downloaded from the script.aculo.us site.

Thanks for the comment,
Brian

@ Fransjo: Hi Fransjo, like all JavaScript form validation scripts, this one just won’t work when JavaScript is disabled.

You should never rely on JavaScript being enabled and should always double check the form server side. This script is meant to compliment the server-side validation.

You could use a hidden input field to tell the server which fields are required (with it’s value attribute populated with a comma seperated list of required input names and regular expressions perhaps) .

Thanks for the comment,
Brian.

@ jojje: Hi jojje, you can use the callback functionality to check the two field values are identical, if their not, return false from the function to stop the form submitting. Hope this helps.

Regards,
Brian.

@ JOJJE: Hi Jojje, assuming your two input's have the id's "pass1" and "pass2", something like this should suffice as the contents to the callback function:

  
  // Only check the two fields are identical when the user presses submit
  if(onsubmit) {
    var p1 = document.getElementById('pass1');
    var p2 = document.getElementById('pass2');

    var p1val = p1.value;
    var p2val = p2.value;

    if(!p1val || !p2val || (p1val != p2val)) {
      // We have an error

      // Do your error alert (or similar) here
      // alert(‘The password confirmation does not match the password’);

      // Return false so the form does not submit
      return false;
  }

  // Return true as were validating individual fields
  return true;        
  
  

You can email me at brian (at) modernartcafe [d0t] net should you need any more info (I'm slightly pressed for time so the answer might not be immediate).

Hope this helps,
Brian.

@ Greg: Hi Greg, yep, theres little to no info available about comments in the DOM. I know for sure that IE 5/5.5 don’t even add them to the DOM – it’s a pity Safari does the same.

@Flesher: Hi Flesher. You can’t pass regular expressions in the class attribute as they contain characters that are illegal to use in a className (the ^ character for example). This was the entire point of using comments to store the regular expressions. The script could be rewritten to search for comment nodes after the form input’s and not before – this might alleviate some of the cut & paste worries.

Regards,
Brian.

@ Tom & Daniel: Hi guys, remember, this is an experiment and was never intended to be used within production environments!

In fact, I have an improved version somewhere on my harddrive that combines all of the validation rules into a single JSON block hidden within a single comment node.

As for Safari, there’s no way the script will work until the Safari team integrate comment node suppport into their DOM parser.

Another problem is that comments within the document invalidate your page if they contain anything but comments (ok, the page will pass “machine” validation but not “human” validation). As we are using the comment nodes(s) to store data, it (like IE conditional comments) breaks the W3C comment rule and therefore breaks (human) validation.

I’ll try to post a copy of the new (unfinished) code sometime this week. Feel free to improve it (or suggest improvments).

Sorry I can’t be more help,
Brian.