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 : juxtapo

juxtapo now passing jsLint

I have been doing a lot of work on the next version of juxtapo (version 0.7). I’m heading towards the big 1.0 release where I want to have a stable and consistent API along with a well tested and reliable system. Part of this has been to get the core juxtapo library passing jsLint tests.

Here is a screen shot of the current version 0.7a:

Also thanks to Arnold Zokas the combiner project will be separated and see some significant improvements to functionality and stability.

Work on the juxtapo website has started and I’m thinking of including a config generator to get people off to a quick start.

Del.icio.us : javascript, jslint, juxtapo

Finally managed to release a beta for juxtapo

Phew, I’ve been working hard at getting unit tests done, bugs ironed out and docs written so that I can get a release of juxtapo out and now it’s here.

juxtapo is a personal project I’ve been working on which gives in browser overlays and previews for template building. It’s been so valuable to me in my day to day work that I thought I should share it out.

So take a look and let me know what you think.

Javascript development and deployment strategy – Part 1

With the popularity of JavaScript rising significantly the amount of code within one project has grown to the extent where it needs to be separated in to separate files unless you want to be scrolling through thousands of lines of code. Whether you do this per class or namespace is another debate but I have been thinking through how all these separate files might be combined appropriately and compressed at deployment.

I have decided to itemise what I would ideally want to achieve and maybe some thoughts on how i could do it.

1. I want to be able to split code in to appropriate sections so that i can save them across multiple files.
   • this will make it easier to find code
   • this will make code more modular and help to debug
2. I only want one script reference within the html file even at dev time
   • i don’t want to annoy the back end devs with the hassle of different versions of the html head area
   • i want to manage easily the order in which scripts are loaded and which scripts are grouped together.
   • i want the dev to mimic the live environment as closely as possible
3. I want a system which is flexible enough to allow me to specify which scripts get combined on deployment
   • if there are sub sections to the code which change more frequently to others i don’t want the client to have to download the full whack when something small has changed
4. I want this to be extremely painless to implement
   • pain is not that desirable to me

With these four requirements in mind I set about my strategy and have come up with this:

1. a root file for each set which at dev time dynamically adds the linked files to the page
2. You can have as many root files as you want and you only need to maintain one list of links within each root file.
3. It only takes 3 very simple steps:
   1. copy and paste short section of standalone code in to a root file
   2. set the root file js name
   3. include a list of files which will be combined on deployment

In part 2 I will give a demonstration of this in action.