There’s always a lot going on behind the scenes with the MooTools javascript framework. And how could there not be? Here’s a look at what’s coming in the next few months.
As we turn our attentions towards MooTools 2.0, version 1.2 will not receive any significant upgrades. However, until MooTools 2.0 is released we will continue to support the current version with bug fixes. To that end we’re releasing MooTools Core 1.2.4 which fixes several small bugs and addresses a change coming in the next release of Firefox. Because of this inconvenient Firefox change, we’ll also be releasing MooTools Core 1.1.2, an update to the 1.1.1 release. Sites using 1.1.1 will be able to drop in 1.1.2 without it affecting anything. We’ll post more details on this when we release these two updates.
While the 1.2 version of MooTools Core no longer accepts additions, MooTools More, the official plugins collection, continues to be iterated upon constantly. Included in the next version of MooTools More (1.2.4.1) are numerous bug fixes and performance enhancements, along with new widgets, classes, and extensions for you to play with. Here are a few:
Another plugin coming in MooTools More 1.2.4.1 is a client side dependency manager. This class allows you to lazy-load files from the MooTools libraries and any other libraries that use similar organization (i.e. those that map their dependencies with the same mechanisms).
In addition to this client side implementation of the dependency loader is a server side version that greatly improves performance. The server side implementation concatenates and (optionally) compresses the files together so that there’s only one request and is far more efficient.
MooTools ART has been under development off and on for nearly a year now and for the most part has been under wraps. MooTools ART is the foundation for MooTools’ upcoming UI library. Using canvas and VML, it features support for dynamic illustrations, allowing complex UI elements that have numerous interactive states. When released, will come with numerous plugins for stylable windows, buttons, and more.
One of the most interesting ART features is its support for themes using CSS-like syntax in javascript. In conjunction with the default widgets that come with ART we hope to see the MooTools community create numerous interfaces using the system that allows for a fully themable UI by the end of the year.
Anyone who has been around the MooTools forums or IRC channel has heard that the user plugin catalog (which we call the Forge) is always “coming soon”. Well, this time, we mean it. The MooTools Forge is a new application which will act as a central repository for MooTools plugins created by, well, by you. The Forge will pull your code directly from GitHub, taking into account versioning and dependencies, and providing plugin usage details.
The Forge is currently in the last stages of testing. Look forward to seeing the MooTools forge by the end of October at the latest.
MooShell is an outstanding interactive shell editor for debugging your MooTools code created by Piotr Zalewa. Instead of pasting your CSS, javascript, and HTML into static PasteBins, you may use MooShell to show others the issues you are experiencing with your code. You may also quickly experiment with different techniques and share your ideas with others.
Your favorite javascript framework is about to become 1.612903225806452 times as awesome. MooTools 2.0 will feature an optimized Fx library, an improved Class class (one of the foundations of the entire framework) and inheritance model, blazing fast selector engine (Slick), numerous speed optimizations, and many more goodies. Look forward to a more detailed post soon!
Since the dawn of time, MooTools used a method named $ to get an HTML element by it's id or direct reference. This method name, being the coolest and shortest you can find in JavaScript, is also used by a number of other javascript frameworks and libraries for similar functionality. Now, we do not think including 2 libraries or frameworks is OK. It's not. Never. It's an overhead of duplication you do not want to have. However, you might not have the full control of the page in some circumstances, and we recognize that. That's why we implemented this: Dollar Safe Mode™. It's nothing special really, but it should help in those situations where including multiple libraries is not your choice (because if it is, quite frankly, you're doing everything wrong. Pick one, will you? And make sure it's MooTools :-)).
MooTools 1.2.3 DOM stuff doesn't depend on the presence of $ anymore. The method that used to be $ is now called document.id (short for identify). The method $ is still assigned when not already present in the page, and aliased to document.id.
But let me show you how it works:
Let's say you have mootools.js and a fictional JS library called jLib.js. Both use a method called $.
<script type="text/javascript" src="mootools.js" />
<script type="text/javascript" src="jLib.js" />jLib would "steal" the $ method from MooTools. MooTools doesn't work unless jLib has some sort of no-conflict mode of its own that will allow you to prevent it from "stealing" $ from MooTools.
<script type="text/javascript" src="jLib.js" />
<script type="text/javascript" src="mootools.js" />MooTools would "steal" the $ method from jLib, which may or may not work without it.
Scenario 1: Include MooTools first:
<script type="text/javascript" src="mootools.js" />
<script type="text/javascript" src="jLib.js" />MooTools checks if a method called $ exists; if not, it defines it. In this scenario, MooTools defines it as it doesn't find anything named $, being included first.
jLib "steals" the $ method from MooTools.
MooTools doesn't care. MooTools now doesnt need $ to properly function. You can regain control of $ simply by reassigning it to its alias ($ = document.id).
Scenario 2: Include jLib first:
<script type="text/javascript" src="jLib.js" />
<script type="text/javascript" src="mootools.js" />MooTools checks if a method called $ exists. It does find it, being included last, therefore it doesn't define it. You can directly use document.id() or assign your own var to it, or manually assign $ to document.id, if you would like MooTools to have control of it.
As you can see, it's pretty straightforward. In short, MooTools doesn't need $ to function anymore, and doesn't steal it from other frameworks when included after them.
The above applies for MooTools-Core and MooTools-More. However, MooTools plugins use the $ method, therefore, while not breaking MooTools by including jLib, you will break the MooTools plugins. If you desperately need plugins to be multiple-framework compatible, and you the other frameworks to have control of $, there are a few things you can do.
The first, most obvious and recommended option is to replace every call to $() with document.id() by hand. It doesn't take more than 10 seconds with a simple find and replace. This is probably what plugin authors should do, if they wish their plugin to be dollar-safe.
Another option is to encapsulate the plugin using a closure. This might come handy if you are processing a plugin that isn't yours:
var X = new Class({
initialize: function(element){
this.element = $(element);
}
});it should become:
(function(){
var $ = document.id;
this.X = new Class({
initialize: function(element){
this.element = $(element);
}
});
})();As you can see, we've simply assigned $ as a local variable, using a closure. Everything in that closure will use document.id as its $ method. Remember to export the global variables though, as vars defined in the closure will stay private. I like to export globals using this., but you can use window. as well.
Please note that MooTools will probably remain incompatible with other frameworks that modify native prototypes, as there will probably be more name clashes. This isn't a cross-framework compatible MooTools version by any means, nor does it want to be. The whole point is not to "steal" the dollar function from other libraries.
And that's pretty much it about the Dollar Safe Mode™ in MooTools 1.2.3.