I have started using Backbone.js but with handlebars templates (like in Ember.js) that I parse through Underscore.js. Anyway, to cut a long story short – I did not want to have a bunch of flat script tags with HTML in the document body on page load so I thought of a way to lazyload and bring the templates from an external repository.

The result is Asset.templates – written in the style of MooTools more’s Asset.images/javascript or whatever. The idea is: it uses Request.HTML to fetch the template file; it then injects it as a script tag into the document.head; it sets the correct type (text/x-handlebars in the example but it’s an option) and a property that lets you use a selector engine to reference and load it (data-template-name in the example, but it can be anything, including id – if you like).

It loads the files asynchronously and firess onProgress and onComplete events – as well as onFailure. If any template is missing and onFailure fires, it won’t fire the onComplete so you can recover early.

Loading a template a second time will NOT inject a new script tag but will update the existing template instead.

Here’s a gist with the code and an example case:

Full gist here: https://gist.github.com/1768949

There was notiMoo and I am sure there have been other javascript/mootools Growl notification solutions already. Yet, none of them were CSS3 and mootools 1.4 friendly, so I created a new Class instead.

Check out mooGrowl on GitHub
https://github.com/DimitarChristoff/mooGrowl

View the demo on jsfiddle:
Full screen or normal jsfiddle

Screenshot of some Growls:

This is somewhat trivial but is also useful and is a common question that a lot of people ask. The problem is in 2 parts: How to instantiate a Class based upon a dynamic name/variable and how to identify the Class name that has created a MooTools Class instance (the prototype, really).

First of all, to make a dynamic instance based upon a variable name, you simply need to know the name and context of execution (scope) of the Class you want to instantiate.

// define the class in the current scope / global object
this.foo = new Class();

// define the class in a namespace
var namespace = {
    foo: new Class()
};

// get the variable class name we need to use from any source into a variable...
var dynamic = 'foo';

// make the instances
var instance1 = new this[dynamic]();
var instance2 = new namespace[dynamic]();

So far, so good. This is pretty standard javascript and is self explanatory.

The harder bit comes when you have an instance and you are trying to find what Class name it is an instance of. We will create a small function that can help:

function getClassNameOfInstance(mootoolsClassInstance, context) {
    // query the context (this or custom object) for the instance we are working with
    return Object.keyOf(context || this, mootoolsClassInstance.constructor);
}

// use it on the global object
console.log("instance1 is: ", getClassNameOfInstance(instance1)); // foo

// use it on the namespace object
console.log("instance2 is: ", getClassNameOfInstance(instance2, namespace)); // foo

This function will check the context object for the constructor of the instance and return the ‘key’ if it matches, which will be MooTools Class name.

I hope it helps someone out there. Check it on JSFIDDLE: http://jsfiddle.net/dimitar/S4rR6/2/

We all know and love Asset.js from MooTools-more. It affords you lazyloading by providing Asset.javascript, Asset.image, Asset.images and Asset.css. However, sometimes you need more precision when bringing in external scripts as dependencies.

Hence I created my own Asset.javascripts – based losely on a coupling of Asset.images and Asset.javascript but providing sequential asynchronous loading.

Asset.javascripts = function(sources, options) {
    // load an array of js dependencies and fire events as it walks through
    options = Object.merge({
        onComplete: Function.from,
        onProgress: Function.from
    }, options);
    var counter = 0, todo = sources.length;

    var loadNext = function() {
        if (sources[0])
            source = sources[0];

        Asset.javascript(source, {
            onload: function() {
                counter++;
                options.onProgress.call(this, counter, source);
                sources.erase(source);

                if (counter == todo)
                    options.onComplete.call(this, counter);
                else
                    loadNext();
            }
        });
    };

    loadNext();
};

Eg. usage with Arian’s DatePicker class, which uses multiple files that need to be loaded in their right order:

if (!window.Picker) {
    new Asset.javascripts([
        "/js/mylibs/Locale.en-US.DatePicker.js",
        "/js/mylibs/Picker.js",
        "/js/mylibs/Picker.Attach.js",
        "/js/mylibs/Picker.Date.js"
    ], {
        onComplete: function() {
            new Asset.css("/js/mylibs/datepicker.css");
            new Asset.css("/js/mylibs/datepicker_dashboard/datepicker_dashboard.css");

            doDates();
        }
    });
}
else {
    doDates();
}

Have fun.

Update: Thanks to @CarstenSchwede, who pointed out that the MooTools Class Constructor expects the Extends mutator __before__ the Implements one, meaning you don’t need to worry about any of the stuff I had to come up with (described in this post). Upon further investigation with Arian, it turns out that MooTools 2.0 will NOT be dependent on order of Extends and Implements declarations in classes, thanks to this change by Kamicane.

The neverending debacle of Extends vs Implements, which one to use and how to use them together – has been a source of discomfort for me in MooTools for a while so I thought I’d write up parts of my experiences with it in the hope it may help somebody else.

I came to have a need to write a class that serves as my new mixin and brings a new method ‘kill‘ – (say, Class ninja) to another class (Class badass) that extends Class human. Pretty crazy, right?

The problem is, the pattern of:

var ninja = new Class({
    kill: function() {
        alert("kill!");
    }
});

var human = new Class({
    initialize: function(){
        alert("i r human!");
    }
});

var badass = new Class({
    Implements: [ninja],
    Extends: human,
    initialize: function() {
        alert("i r badass and.. ");
        this.parent();
        this.kill();
    }
});

new badass(); // i r badass, i r human, this.kill is not a function exception.

… simply does not work. The Extend here means the human prototype is the base and it lacks the kill method. Wut?

The main practical difference in subclassing approaches is that the `Implements` (mixin) does not instantiate the subclass whereas `Extends` does, so there can be only one class that is extended whereas implemented ones just copy the methods from the prototypes. How to get around being able to extend a single class only? You need class human to implement ninja instead and class badass to simply extend human. Aside from the side-effect of humans getting a new kill method (which they may or may not know about), it will mean that badass will be able to use .kill as well as call upon his direct parent human.

The whole point is, you may not always be at liberty to rewrite / refactor classes the way you want them without creating complications with other parts of your web app. You could also be be extending a Mootools native class like Request.JSONP and then decide to mixin a new storage class into your extended one (true story!)…

An interesting pattern (or rather, the only pattern I have found to work… ) to overcome this goes something like this:

var ninja = new Class({
    kill: function() {
        alert("kill!");
    }
})

var human = new Class({
    initialize: function(){
        alert("i r human!");
    }
});

human.implement(new ninja);

var badass = new Class({
    Extends: human,
    initialize: function() {
        alert("i r badass and.. ");
        this.parent();
        this.kill();
    }
});

new badass(); // this.kill works.

You could even write this as:

Extends: human.implement(new ninja),

Obviously, you can simply modiy the prototype of the parent class and do:

human.implement({
    kill: function() {
        alert("kills!");
    }
});

But this means the code you already have in ninja needs to be duplicated and this will go for all methods or properties you want to gain access to.

A practical example with Request.JSONP and an example caching class, created to allow use of localStorage. Why would you want to do that? Well, having a class that can allow you to cache replies from Request or Request.JSONP or anything at all is handy. And doing things that fetch non-volatile data through a rate-limited API is expensive, you are encouraged to cache. In other words, if you read a particular user’s Twitter profile / timeline, you should not have to request it again on a reload within the session. Same applies if you are expanding tiny URLs like bit.ly – the URL won’t change for any given hash so there’s no point in continuously fetching it.

In the following example, we cache the response for a user profile JSONP request via the Twitter API:

View the full fiddle here: http://jsfiddle.net/dimitar/AjP5A/.

For a real detailed explanation of Extends vs Implements in MooTools, grab a copy of Pro Javascript with MooTools by keeto.

This was completely overhauled.

Basically, I just released a new mootools modalBox Class called ‘baseBox’. You can see it on jsfiddle and play with it some. Full details, documentation are available on the project github page.

Features:

• Full CSS support – whatever you do, it assigns to the box.
• Complete control – plenty of options, events and instance references for any scripting scenario
• Window nesting / grouping
• Auto toggle when called on the same parent element
• Smart closing through delegation
• CSS3 shadows, gradients out of the box.
• degradation to solid colours and image urls as fallback via CSS
• CSS2D transform support – scale for FireFox, WebKit, IE9, Opera(untested?) via standard Fx.morph!
• degradation via a simple fade when not supported

__VERY_ flexible – should be used as a base to extend. For example, to make a class that Extends baseBox that deals with lightBox-like image only display, here’s all you need to do: baseBox.lightBox.js demo. The lightBox demo is also included in the package and is on GitHub.

Similarly, you can make your own sub-classes, for example, baseBox.Request can work asynchronously to get HTML fragments and show them to the user.

Ever needed to clone an element and take your element storage with it? I have and it’s not easy. There’s Element.cloneEvents(), which takes the storage.events callbacks but any other storage you may have used remains unavailable behind the closure that MooTools uses for the storage object.

This bit of code tracks of any data you store (via the lstore method only) in the element’s native storage and then provides a new Element prototype Element.cloneStorage(srcElement).

(function() {
    var eliminateOrig = Element.prototype.eliminate;
    var localStorage = {};

    var get = function(uid){
        return (localStorage[uid] || (localStorage[uid] = [])); // converted to an array to store keys stored
    };

    Element.implement({
        lstore: function(property, value) {
            // use this instead of Element.store
            var storage = get(this.uid);
            // store the key so we can clone it after
            if (!storage[property])
                storage.push(property);
            return this.store.apply(this, arguments);
        },
        eliminate: function(property) {
            var storage = get(this.uid);
            storage.erase(property);
            return eliminateOrig.apply(this, arguments);
        },
        cloneStorage: function(from) {
            // new prototype to clone
            var other = get(from.uid);
            other.each(function(el) {
                this.lstore(el, from.retrieve(el));
            }, this);
            return this;
        }
    });
})();

Here is an example usage test:

document.id("bar").lstore("hello", "there");
document.id("foo").lstore("foo", "bar");
document.id("foo").cloneStorage(document.id("bar"));

// if clone works this should now say 'there':
console.log(document.id("foo").retrieve("hello"));

document.id("foo").store("ugly", "face");
console.log(document.id("foo").retrieve("ugly"));

// testing eliminate.
document.id("bar").lstore("eliminateTest", new Image());
document.id("bar").eliminate("eliminateTest");
document.id("foo").cloneStorage(document.id("bar"));
//should now be null
console.log(document.id("foo").retrieve("eliminateTest"));

To view this on jsfiddle: http://jsfiddle.net/dimitar/225HJ/

And the gist: https://gist.github.com/833584

Thanks to Tim Weink (Timmeh aka FunFactor) for the inspiration and also for pointing out that copying ALL storage is not a good idea due to class instances being stuffed there for things like Fx.Tween / Morph / Request etc, hence making me refactor it to only clone the storage that was passed through the lstore method.

Recently I had cause to revisit my old routine that checks if a browser can work with base64-encoded images. This is a test that modernizr does not offer so the only way to do so is to Feature-detect. To the rescue: an empty 1x1px gif image gets encoded and is then set as the src of a new Image element, then tested. If base64 is supported, the resulting image object will have width and height of exactly 1px.

Here’s the code, extending the MooTools Browser.Features object, NEARLY synchronous (best check with a 50ms delay though or loop while Browser.Featrues.base64 === null):

(function() {
    Browser.Features.base64 = null;
    var callback = function() {
        Browser.Features.base64 = this.width == 1 && this.height == 1;
        // alert(Browser.Features.base64); // true || false
    };

    var img = new Image(), img = document.id(img) || new Element("img");
    img.onload = img.onerror = img.onabort = callback;
    // 1x1 px gif to test with
    img.src = "data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///ywAAAAAAQABAAACAUwAOw==";

})();

And to see it in action:
http://www.jsfiddle.net/dimitar/5JT45/13/show/ or editable jsfiddle

Gist: https://gist.github.com/821370

An encoding tool that can help you convert your images: binary to base64 translator.

In reality, IE7 upwards supports it fine so all this “Feature Detect” can be skipped but it’s somewhat nicer that way.

Here’s the next instalment in our Intermoos series: we sit and talk with Ryan Florence, one of the most extraordinary and well respected coders, the man behind moo4q, SlideShow, mooDocs and the MooTools magazine. I thought he was Italian (or at least French) for a long time. I was wrong…

Is that your ostridge there? Thanks for your time!

Great timing is essential to great interviews (cough) but this one really is a cracker. Mark Obcena only had the official announcement / release of his new book “Pro JavaScript with MooTools” earlier today (after great anticipation, if I may add).

So, what better time to get a few answers from the man of the moment than right now? I present to you the “Dr. Keeto” intermoo. Brush up on your “keetology” and start reading!

Thank you for your time!

P.S. Now that the book is hot off the press, I should mention Keeto is available to pester with _interesting_ problems on IRC (just like most other teams in the MooTools community) – freenode.net #mootools. Go and say “hi” and say Dimitar sent you