Mooml is a templating engine for Mootools. With it, you can create HTML from Javascript using a very clean syntax. Plus, it is extremely useful when you have to generate repeating elements, since Mooml automatically renders arrays of data multiple times. Let’s see an example.

Searching Twitter

Nowadays there are a lot of APIs out there that support JSON or JSONP, which we can use directly from the front end using Javascript. Also, there are other APIs that return tons of JS data, like Google Maps. In this example we are going to be searching Twitter and displaying the search results in a container div, properly rendered as HTML.

The url for searching Twitter is http://search.twitter.com/search.json?q=mootools&show_user=true (searching for Mootools in this case). Check the output:

We want to render each result inside out container div. On this example, we will just render the user name, user image and message text. Here is our Mooml template:

Since all results are returned into an array, we can pass it directly to Mooml which will render all of the elements in it:

So, let’s do a live test. Type something you want to search for and hit the search button to see Mooml in action :)

Search:

How cool is that?

The code

Ok, so here is the whole code I have used in this post for this mini-demo:

As you can see, the code is very basic and so is the Mooml template. The coolest thing here is that you don’t need to iterate over the results to render each element.

Have fun!

Since version 1.0.9, Mooml includes a new feature: globalize. It maybe handy for some websites to globalize all the Mooml template functions (div, a, p, span…) to the window object scope, so they can be used anywhere in the code without the need of defining or evaluating a template.

For example, in normal Mootools code we would create a div like this:

With Mooml.globalize() we can do this:

Mooml globalized functions can also have nested elements, which makes very easy to create dom elements:

Will generate the dom elements for this html:

Elements created by Mooml template functions are not automatically injected in the DOM. They are just created like when you use new Element().

Please be aware that using Mooml.globalize() feature will pollute the window object scope, overriding any methods with the same name and/or possibly conflicting with other Javascript libraries. As a tip, Mooml.tags can be edited before calling Mooml.globalize(), so only functions for those tags we are interested on will be created.

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 ;)

Sometimes we need to create HTML from JS. There are multiple ways to do this, from using innerHTML to creating element by element appending child to parents, setting attributes, etc. And there are as many different opinions about what is the right way to do it.

Meanwhile, once thing I missed from jQuery, not available on Mootools, was the ability to do something like this:

In Mootools, the equivalent should be:

But that does not work.

On the Mootools mailing list, someone was asking about how to implement this and we just found a different approach, which instead of using the Element class, extends the String class like this:

Now you can do this:

To try it, paste this snippet on Firebug’s console:

Nice, uh? Of course, the HTML can be as complex as you need and where do you get the content of the string is up to you :)

I found specially interesting the use of document fragments.. Didn’t know about them before :)
http://james.padolsey.com/javascript/javascript-bad-practices/

Although I haven’t need them for my classes, I thought it would be very cool to have the possibility to use them. Setters and Getters are very popular in modern programming languages, since they let you do some actions when a member/property of an object is being accessed or modified. Setters and Getters are native on Javascript objects.

Well, Mootools objects created using Class do not support that syntax. Fortunately, we can use the __defineSetter__ and __defineGetter__ functions:

Nice, uh?

I was watching one of the video tutorials from Apple last night about some custom JS available on Safari, only on the iPhone 3.0, that let’s you interact with the phone and obtain data like the current location, etc.

So I built a little page to see how it works. I included Mootools 1.2.3 from Google servers and the Google Maps API. And voilá, with a few lines of code we have a totally functional web based GSP navigation system. A little bit ugly, but functional. Currenlty it only centers the map on the coordinates given by the phone, and also does a reverse geolocation to obtain the address (actually city, state and country). But it could be easily extended to add markers to the map, or even paths to track the movement.

If you have an iPhone (or an iPhone simulator) go to:
http://enekoalonso.com/research/iphone/geolocation.html

The source code:

Enjoy.

When applications (or websites) get pretty big, it usually happens that a lot of different objects or classes interact with each other or, even worst, depend on each other to achieve the site functionality.

A simple example could be a Tabs manager class, which controls a set of tabs in the page. Sometimes, the content in this tabs is sensitive to when the tabs are shown or hidden. At this point you have three options: either the Tabs class needs to know about the content or you create a set of callback functions or you use custom events. Still, for every one of these options you are going to need variables referencing the instances of your classes (this is: var myTabs = new Tabs())

Personally, I don’t like having global variables for the objects I create. I think the code gets very messy and complicated.

So, after dealing with all these issues at work day after day I thought it would be very cool to have a messaging system between my classes, the same way other languages like Cocoa do (in a more simpler way, at least for now).

Sending messages between classes

Wouldn’t it be nice if the Tabs class would send a message every time a new tab is selected? Wouldn’t it be nice if the objects that are going to reside inside those tabs could listen to that message and update accordingly?

To do this, I created a Base class and a Register, where my objects will register automatically upon instantiation (thanks to the Base class).

As you can see, the register is just an array of Instances. Yes, Register is a global object, but it will be the only one we will need. Meanwhile, the Base class adds the new instance to the Register automatically. For convenience, the Base class has a sendMessage method. Also, for convenience, I like to add a ClassName property to all my classes in case I need it later for logging, instance class type identification, etc.

Now, thanks to MooTools, we can create our classes and make them inherit from Base. We can override the processMessages method and act accordingly:

The beautifulness of this code resides, as I mentioned before, in the absence of any object references. Tabs doesn’t know anything about the VideoPlayer class nor any other object listening to the messages. And the VideoPlayer doesn’t know anything about the Tabs class either. It only knows about the message it has to listen to. No object references, no methods, no callbacks.

Pay attention now. This is the best part! Whenever we instance our classes, no matter how many times we do, we don’t need variable references anymore:

Nice, uh?

Since I implemented this class I use it a lot on every project at work. It makes my life easier, keeping my classes simple and independent from each other. It’s even better. We have got to a point where we have integrated this feature with our Flash components, so these send messages to the Register when needed and any JS object listening reacts to them as needed.

By doing this, even being unidirectional (Flash to JS only), we have achieved something great: from now on, our Flash objects don’t need to know anything about our JS objects at all. Just send a message to the register and done.

At any point, even from Firebug, you can send a message to the Register. This is very nice, even for debugging:

A listener class

I found it is very nice, while in development, to have a Listener class debugging any message received. This way I don’t need to add a console.log call on all my classes to output received messages. The Listener will do it for me:

Even you can control the Listener by sending custom messages to it! Awesome!

Could this be achieved with custom events?

With Mootools, creating custom events is piece of cake. But from what I understand, custom events work only inside the object that is firing them. This is, if object A fires an event ‘customEvent’, you can only listen to it if you add a callback function when you instantiate that class:

Ideally, B should be able to listen to the bodyClicked event without passing any info when A is instantiated. But if I’m not mistaken, this is not possible.

Revised version

I decided that it would be cool to have the Messenger as something my classes could implement, instead of inherit from (Base). Also, it would be good if one object could register for a specific message only, which would improve performance too.

Here you go!

It may seem trivial but it has its tricky point. Usually, in procedural Javascript (this is, non object oriented programming), timers are set up passing the callback function on a string:

For this code to work, hello() has to be a global function (actually a function of the window object). Otherwise, when the timer times out, it won’t find it.

When writing object oriented code, one would like to call a function inside the object itself, not a global function. We can achieve this passing an anonymous function to the setTimeout function that calls our function:

The previous code wont work, since this inside the anonymous function points to the window object and not to our instance of MyClass. We solve this using the bind function provided by Mootools:

This code will work fine, but it still has a big problem. If we wanted to access any member or function of our instance inside the hello() function, it wouldn’t work. This is because when the timer times out, the context of our instance is lost. Inside the hello() function, this will point to the window object.

There are multiple ways to solve this issue but my favorite is to use the function call() of the function object. This function let’s you pass an object while calling your function that will become this inside it.

Now we can use this inside the hello() function and everything will work fine, no matter how many instances of MyClass we create.

Enjoy :)