Archive for May, 2010

Including jsLint in your validation using nAnt, batch files or AJAX

jsLint is a fantastic tool developed by Douglas Crockford, Yahoo!’s JavaScript architect which will validate JavaScript source to a strict specification which often catches hidden errors.

As the website says jsLint will probably “hurt your feelings” as it enforces conventions which not everyone would like…however, I would recommend you include it within your build scripts and work through any issues it throws up. You will be grateful of it in the end!

I am going to take you through ways to integrate jsLint in to a nAnt build process, or just be able to run it manually locally on Windows.

You can download all the example files for this post.

Setup

Download the relevant files needed and customise the jsLint.wsf defaults (line 56) to fit with your preferences. I have included a less strict version for this example.

1. Running jsLint manually

You can run jsLint manually on your js files by passing their location as the first parameter of jsLint.bat. The location can be an absolute or relative location. Here are some examples:

jsLint.bat c:\project\js\test.js

jsLint.bat ..\..\js\test.js

You may want to create another batch file which will run it on multiple files to save you having to type the locations in every time.

2. nAnt build target

You can include these tests within nAnt build scripts so that the build fails if the JavaScript doesn’t validate. Here is an example build target (download).

<target name="jsLintValidation" description="validates JS files">
  <foreach item="File" property="jsfile">
    <in>
      <items>
        <include name="${siteroot}\js\*.js" />
      </items>
    </in>
    <do>
      <exec
        program="${jslintdir}\jslint.bat"
        commandline="${jsfile}" />
    </do>
  </foreach>
</target>

3. Using AJAX within your JavaScript Unit tests

The beauty of jsLint is it is writted in JavaScript, which means that you can use the functionality within a browser. This won’t work on static sites because of security issues with XmlHttpRequests, but if your tests are on a hosted site then you can load your JavaScript using AJAX and run them through jsLint.

It’s as simple as running the JSLINT function (example, download):

var myResult = JSLINT(source, option);

If it checks out, JSLINT returns true. Otherwise, it returns false and you can inspect JSLINT.errors to find out the problems. Details of the structure of JSLINT.errors can be found within the comments of the fulljslint.js file.

Let me know how you find jsLint as a validation tool, or please feel free to ask any questions.

Del.icio.us :
Flickr :

juxtapo plugin framework…feedback wanted

I am appealing for your thoughts. You may have taken a look at juxtapo front end tools which includes an in browser templating system for overlays. It includes an API which has been designed to allow developers to extend the core functionality with plugins. I want to extend this so that juxtapo could be aware of available plugins and also plugins could communicate and be aware of each other.

Juxtapo plugins generally initiate themselves as Juxtapo does and extend the core functionality. An example of this is the QUnit plugin which allows the developer to link a number of unit tests to a particular template. It hooks in to the API and once juxtapo has initialised looks up the current template and runs the tests.

What are your thoughts on the following ways which this could be done?

1. Constructor

This method uses a Plugin constructor to create a Plugin object which could then be assigned to a variable.

juxtapo.plugins.newPlugin = new juxtapo.Plugin({
    init: function(){
        juxtapo.initComplete(function(){
            // functionality added on initConfig
        });
    },
    publicVar: 'public'
});

or

juxtapo.plugins.newPlugin = new juxtapo.Plugin(function(){
    juxtapo.initConfig(function(){
        // functionality added on initConfig
    });
    privateVar = 'private';
    return {
        init: function(){
            juxtapo.initComplete(function(){
                // functionality added on initConfig
            });
        },
        publicVar: 'public'
    };
});

2. Add Function

This method uses a function to create a plugin object with defaults and then allow you to customise it. It would then add the resulting plugin to the variable name provided by the first attribute.

juxtapo.plugins.add('newPlugin', function(){
    // this is the function to construct the plugin which has defaults
    // created already
    juxtapo.initConfig(function(){
        // functionality added on initConfig
    });
    // optional init function which would be fired by juxtapo just before
// iniComplete this.init = function(){}; this.publicVar = 'public'; });

3. Anonymous Function

This method is very open. When juxtapo initialises it will check to see if there is an init function and if it finds one it will call it, otherwise you can attach listener functions to other juxtapo events.

juxtapo.plugins.newPlugin = function(){
    juxtapo.initConfig(function(){
        // functionality added on initConfig
    });
    return {
        init: function(){},
        publicVar: 'public'
    }
}();

3. Create Plugin Function

This works in very much the same way as the add function but uses another function to return an object which can be assigned to the newPlugin variable.

juxtapo.plugins.newPlugin = juxtapo.createPlugin(function(){
    // this is the function to init the plugin which has defaults
    // created already
    juxtapo.initConfig(function(){
        // functionality added on initConfig
    });
    this.init = function(){};
    this.publicVar = 'public';
});

I will be converting the current example juxtapo plugins for the next release v0.8 to use which ever method we feel is the most intuitive and simple to develop with so your help and thoughts will be very much appreciated. If you know of any standards for framework plugins then let me know as well. Thanks in advance.

Del.icio.us :