Tried having a bash with jsUnit today, and got instantly stuck when trying to run a basic test case.

FireFox simply hung, and I really had no idea why.  For the first time, IE8 worked fine!

Thanks to this post, it was straightforward enough to get working.

First you have to modify the jsUnitTestManager.js file, and replace/insert the following code:

function isFF3() {
return (
    navigator.userAgent.toLowerCase().indexOf("iceweasel/3") != -1 ||
    navigator.userAgent.toLowerCase().indexOf("firefox/3") != -1
        )
}

function browserSupportsReadingFullPathFromFileField() {
    return !isOpera() && !isIE7() && !isFF3();
    //return !isOpera() && !isIE7();
}

Secondly, you'll have to disable the draconian security that new FF introduces.  Type about:config in your address bar and then set security.fileuri.strict_origin_policy to false.  This will allow FireFox to access local resources without a problem.

Now it will have disabled the browse to field, so the only way you can run your tests is directly via the address bar, as so:

<path to testrunner.html>?testpage=<path to mytests.html>

Looking at in-line validation for a new website, came across this cracking jQuery component - http://www.position-absolute.com/articles/jquery-form-validator-because-form-validation-is-a-mess/

Couple of gotchas to remember with this:

• It expects the validation class to be FIRST.  So you'll need to remove existing classes and then add them back again at the end.
• It has a bug whereby when you resize/move the window the error divs draw in a new position.  I've fixed this by modifying the buildPrompt() function as below:

 var divErrorId = 'divError_' + linkTofield;
        $('#' + divErrorId).remove();
        
        
        $(divFormError).attr('id', divErrorId);

This very simply identifies each error div according to the field it is displaying against, and removes any existing ones before it adds a new one.

Best practice would be to do this automatically rather than in-line, so you may want to have a function like so:

function registerValidation(id, validation)
{
  //validation has to be the first class declared
  var elementClassList = $(id).attr('class');
  $(id).removeClass(elementClassList);
  $(id).addClass(validation);
  $(id).addClass(elementClassList); 
}

call this from doc.ready in your page as so

$(document).ready(function() {
   
  registerValidation("#txtMyField", 'validate[required,custom[onlyLetter],length[0,100]]');

I haven't tested the above code to any great degree yet, leave a comment if you spot any goofs!

Also, there appears to be another bug if you want to call the javascript directly, so you need to make sure you set the settings like so:

  var settings = jQuery.extend({
      allrules:allRules,               
      inlineValidation: true,   
      ajaxSubmit: false,
      promptPosition: "topRight",   // OPENNING BOX POSITION, IMPLEMENTED: topLeft, topRight, bottomLeft, centerRight, bottomRight
      success : false,
      failure : function() {}
   }, settings);

$.validationEngine.loadValidation("#txtAddressLine1", settings); 



Then you want to check

Code: Select all

$.validationEngine.isError

for an error.

Came a cropper with this today. Wired up a $.ajax() event to my [button] thinking that all should be well.

Couldn't understand why the ajax call was terminating BEFORE the code on the server side was being called, even though the server side code was actually being called!

Should have known this, but [button] behaves as a Submit button under all browsers except IE, if you don't mark the "type" attribute.

See http://www.w3schools.com/tags/tag_button.asp for more info