Back in November 2008 I had a chance to work with Dojo on a project for Cisco WebEx. I didn’t like it at all. I was used to the simplicity of jQuery and Mootools and I couldn’t understand how Dojo had been designed so complicated. Well, one year later I just realized that it is not that Dojo was that complicated. It is that I wasn’t ready for it. Now it is time to give it another chance.
Some cool stuff about Dojo
Reading Dojo’s documentation I have finally understood something that I was wondering how it works. It’s nothing really complicated, but it’s actually very cool: dojo.require
Javascript requests to the server are asynchronous (not sure if synchronous request can be done). So we depend on callback functions to continue the flow of your program. That means that when we put dojo.require('somefancyjs'); on a line, the execution does not stop and it continues to the next line of code while the browser downloads that file from the server in the background.
Looks like Dojo puts those requests on some kind of array, array that is checked when you use dojo.addOnLoad() which does not execute your callback function until all elements of the array have been downloaded. That is very cool because that means you can do as many dojo.require’s as you need. The down side is that you need to put your code inside a callback function, which is not very bad when working with objects.
Next, I have to find out how goog.require works ;)
To do list:
That’s it for now. Let’s see if I can find time to do all those.
Updated
Asset.css claims to have an onload event in Mootools documentation, but sadly, not all browsers support this feature. Even worse, browsers like Chrome seem to support the event, but never fire it.
After some research and testing at work, we have come up with a solution that overrides Asset.css to detect when CSS gets loaded by the browser using the onload event in those browsers that support it (Internet Explorer and Opera) and doing polling in those that do not (Chrome, Safari and Firefox). Here is the code:
-
// Add callback support to Asset.css for all browsers
-
Asset.css = function(source, onLoad) {
-
var link = new Element('link', {
-
rel: 'stylesheet',
-
media: 'screen',
-
type: 'text/css',
-
href: source
-
});
-
-
if (("onload" in link) && !Browser.Engines.webkit()) {
-
if (onLoad) link.onload = onLoad;
-
} else {
-
(function() {
-
try {
-
link.sheet.cssRules;
-
} catch (e) {
-
setTimeout(arguments.callee, 100);
-
return;
-
};
-
if (onLoad) onLoad();
-
})();
-
}
-
-
link.inject(document.head);
-
return link;
-
}
-
-
// Load some CSS and show an alert when done
-
var mycss = new Asset.css('http://example.com/style.css', function() {
-
alert('CSS loaded!');
-
});
-
-
// Unload the css
-
mycss.destroy();
Enjoy!
Up until now I always used subversion and, although haven’t used it much, I liked Google Code repositories a lot. Well, in the last few days I’ve been working with git and github and I have to say that both of them are very cool.
I’ve been using Firebug 1.5 since it was an alpha and now I’m using Firebug 1.6 alpha with Firefox 3.6. I’ve been also using Firecookie for a very long time now, but never realized about this: you can put breakpoints on cookies to detect changes!
Good to know :)
I love Firefox for web development. I have tried other browsers but nothing compares to the power of Firebug. For everything else I used to use Safari 4, but now I switched to Chrome. It is sooo fast.
Either way, don’t miss Firefox 3.6RC2 with Firebug 1.6a!
http://www.mozilla.com/en-US/firefox/3.6rc2/releasenotes/
http://getfirebug.com/releases/firebug/1.6X/
I have been using for a while the “new new Class” syntax to create singletons on the projects I am working on. This is for many reasons, but specially because I didn’t like other solutions like Class.Mutators, Class.Oclude or extending a plain object with $extend().
Now, after discussing a little bit on the Mootools email list about what was the best way to create singletons, I have created Class.Singleton so we can create singletons the Mootools way. Here is how it works:
-
var MySingleton = new Class.Singleton({
-
initialize: function(){
-
// code here
-
},
-
method1: function(){
-
// code here
-
},
-
method2: function(){
-
// code here
-
}
-
});
Using inheritance, mixins, etc
Class.Singleton works like defining any other Mootools class using Class(), so we can have inheritance, mixins, etc.
-
var BaseClass = new Class({
-
initialize: function() {
-
// Initialization code here
-
console.log('BaseClass initialized.');
-
},
-
method1: function() {
-
// some code
-
}
-
});
-
-
var MySingleton = new Class.Singleton({
-
Extends: BaseClass,
-
initialize: function() {
-
this.parent();
-
console.log('MySingleton singleton initialized.');
-
},
-
method1: function() {
-
this.parent();
-
// more code
-
}
-
});
Hope you like it!
Repository url: http://github.com/eneko/Class.Singleton
It was a month ago when I found about Jaml, an excellent small Javascript library created by Ed Spencer which allows generating HTML code using very nice and clean templates. At work we use Mootools in most of our projects, so I thought it would be nice to improve Jaml by taking advantage of the power of Mootools. And this is the result.
Mooml: Mootools markup language
What is Mooml? Mooml is a templating system that allows generating HTML snippets very easily, without all the ugly nested “new Element” calls or string concatenation. With Mooml you can save templates for later use or evaluate snippets on the fly.
Download: http://mootools.net/forge/p/mooml
Source: http://github.com/eneko/mooml
Let’s see an example
Required HTML:
-
<div class="node">
-
<h2>Node Title</h2>
-
<p>Node body here.</p>
-
</div>
Node title and body are variables, so let’s save them on a Json format for now.
-
var data = {
-
title: 'Node Title',
-
body: 'Node body here'
-
}
Using Mootools “new Element” we would have to code something like this:
-
var el = new Element('div', {'class': 'node'}).adopt([
-
new Element('h2', {text: data.title}),
-
new Element('p', {text: data.body})
-
]);
That code is much better than plain Javascript, but still messy. We could use the new Elements.from included in Mootools More 1.2.4, but that would require us writing the html as a string, which rapidly gets messy concatenating variables, etc.
-
var el = Elements.from('<div class="node"><h2>' + data.title + '</h2><p>' + data.body + '</p></div>');
With Mooml…
With Mooml, we can create a template for that piece of code, and reuse it later as many times as we need:
-
Mooml.register('node', function(data) {
-
div({'class': 'node'},
-
h2(data.title),
-
p(data.body)
-
)
-
});
-
document.body.grab(Mooml.render('node', data));
We can also execute the template directly as a function:
-
document.body.grab(Mooml.templates.node(data));
Finally, with Mooml we can evaluate templates on the fly, without having to store them for later:
-
document.body.grab(Mooml.evaluate(function(data) {
-
div({'class': 'node'},
-
h2(data.title),
-
p(data.body)
-
)
-
}, data));
More examples soon :)
On all the projects I’ve worked on, I always try to follow the MVC arquitectural pattern, separating the model from the view *and* creating a controller. It may be a simple controller in charge of a tab-set, or an accordion. Or it may be a full size controller in charge of the whole page structure, on sites that make an extensive use of javascript.
Either way, I always have a controller for a dynamic section of the page and the controller always works with the container of that section. If I need to reference any element inside the container I will use this.container.getElementById() or this.container.getElements(), which will do a search only on the child elements of the container and not on the whole dom tree of the page.
Yes, it is very usual to see nowadays code that alters the links of a page 
we are searching the whole page. And coding like that is just a waste of resources.
