The actual process of developing MooTools itself isn’t trivial. It’s not rocket science, but maybe there is a little alchemy involved. For instance, let’s say you want to fix a bug in MooTools More. You fork the library and make the change to fix the bug and now you want to test it. You need MooTools Core for this, but which version? Looking at MooTools Core on Github you see there’s a branch called 1.2x and also a branch called master, not to mention a tag for 1.2.5. MooTools More has several branches, too; there’s master, develop, 1.3wip and others. Which combination of these two libraries work together?

Then you see some test files in the library. Some HTML files that appear to be demos, but they don’t run on their own. You need to install the MooTools Test Runner to view them (you can see an example of it running at review.mootools.net:9876). And then there’s an external specs runner.

If you decide you want to play with MooTools ART you have similar issues, not to mention the widget library – art-widgets – built on top of it.

While it’s true that jsFiddle gives you a sandbox with a lot of these things, it doesn’t give you a working development environment. In an effort to make it easier to share these configurations, I’ve created a portable development environment that makes it relatively easy to get things up and running.

http://github.com/anutron/mootools-development

I’ve made a github repo that has essentially no code and only submodules pointing to all the stuff I use in states that work. In theory, it should make it really easy to reproduce a development environment from scratch. Eventually I’ll configure several different environments. 1.3, 1.2, 1.1, 2.0, whatever.

Right now there are three environments configured. 1.2.5-art-widgets (which includes everything you need to play with art-widgets), 1.3-art-widgets which lets you do the same against MooTools 1.3 (there are some issues that we’re working on so it doesn’t look great at the moment), and 1.2x-tracking-core-more, which includes just mootools-core and mootools-more on their respective 1.2x branches. These are my personal environments and you can use them if you like.

Note that instead of submodules I’m using crepo. One of the reasons is it will allow us to create a version that’s tracking against a branch. For example, the 1.2x-tracking-core-more branch is always tracked against core/master and more/develop. Typing “./go sync” will update to the latest of these two branches.

The result of this means that we can create specific, deployable environments for others and for each other. I could file a lighthouse ticket against -core with a specific state that illustrates a bug in core/1.3 that manifests itself only in art.widgets (which I’ve done – art.sheet is broken in 1.3).

Note that you don’t have to use django to use the environment. My environment includes the test runner that I wrote and depender. But you can just do ./go sync and get all the repos without building the django app.

This doesn’t have to be specific to MooTools, but that’s what I made it for. I don’t see people trying to incorporate this into other tools, though crepo is designed for that purpose (we us it throughout cloudera).

Several weeks ago I had the pleasure of addressing a large crowd of Joomla developers at their conference in New York. The Joomla community is a fantastic bunch and the time I spent there talking about MooTools was perhaps some of the best I’ve had. The people present were very interested in MooTools and as well they should be. Joomla ships with MooTools built in and there is a large community of Joomla plugin developers who end up using MooTools because of it. Unfortunately, it still ships with 1.1.

A few months ago we, the MooTools team, decided to start focusing more on helping the Joomla community with their upgrade woes and began to re-address the compatibility code for 1.1 to 1.2 in earnest. When I spoke in New York to the Joomla team there and said that our goal was to have something to help them upgrade available by the end of the year, there was, dare I say, rawkus applause.

Well, here it is, Dec 31, and I’ve kept my promise. With the help of many of the MooTools Dev team (Chris Pojer, Darren Waddell, Nathan White, and others) we’ve finally got a compatibility layer that actually works and, more importantly, helpes you upgrade.

First, it logs warnings to the console (such as Firebug) and helps you find the places in your code that need updating. The script is not a compatibility layer as much as it is an upgrade helper. Hopefully this will help us retire 1.1 for good.

Secondly, easily half of the work, if not more, was spent creating a test environment for it. When MooTools 1.1 came out, we didn’t have a test framework to run against the code. When we released MooTools 1.2, we did, and it shipped with tests for most of the functionality included. So to make this compatibility layer, we had to go write tests for all of 1.1 (about 400 individual tests), then write the upgrade helper, compatibility code, and then run the tests from 1.1 against the 1.2 code base with the upgrade helper loaded. Creating the tests for a deprecated code base is no fun but I’m glad we did, otherwise the compatibility code would be in far worse shape.

But as a result of all that work by the MooTools Dev team, I can say that the helper script we released today is likely to cover about 95% of all the changes between 1.1 and 1.2; the other 5% being essentially un-hackable. Still, for most developers, it should cover all their work.

Seeing 2010 roll in with people dropping 1.1 is a great way to start it. If you’re still running 1.1, now is the time to move on.

You can find out more about the upgrade helper on the MooTools Blog.

I know what you’re thinking. It’s been 3 months since I last posted. My last post was all about how you can pay it back to MooTools, and since then I’ve been taking my own medicine.

MooTools 1.2.4 released today along with MooTools More 1.2.4.1. In this release, I’ve pushed 274 commits into the codebase (out of 398). There’s a LOT of new features in it, but some should look familiar.

For instance, my Waiter class is there, now called Spinner. And my Modalizer class is there, now called Mask. Oh, and Fupdate finally got a decent name; it’s Form.Request.

But there’s a lot of other stuff in there, and that’s not even the only place I’ve been cranking. There’s also a dependency loader for lazy loading MooTools scripts called Depender. There’s an all-JavaScript version and a server side implementation (that’s way faster; available as PHP or Python/Django).

And then there’s MooTools ART, which is awesome. It’s the beginning of a UI system for MooTools plugins.

Rather than go over all this stuff in detail though, I’ll just point you to the blog post I wrote over on the Cloudera Blog, which outlines all the cool stuff we’ve been building with all these new toys. There’s even a fancy screencast.

The Clientcide Libs and MooTools 1.2.4

But you’re probably asking yourself, what about the Clientcide plugins? Well, obviously I haven’t forgotten about them. First and foremost, it should be rather obvious by now that much of my work is now being pushed into MooTools instead of released here. It makes sense mostly, as the plugins get reviewed by the other MooTools dev team members and the result is always better. There are still a few plugins here that don’t belong in MooTools More and to that end I’ve been maintaining them, occasionally adding features.

The current version of Clientcide – 2.1.0 – should work fine with 1.2.4. The catch is that the upgrade path to switch to the new instances of the things that moved (for instance, Waiter moving to MooTools More and now being called Spinner), isn’t super duper easy. I do plan on authoring compat layers for some of these scripts, but not all of them.

What does this mean if you’re using these libraries? Well, you can keep using them. But I’m not going to maintain Waiter, for instance. I’ll focus on Spinner. Converting from one to the other should be relatively straight forward, but since they both work in the same space (because they have different names), you should be able to use either one or both.

Look for a release in a week or so of the next version of Clientcide for MooTools 1.2.4. There are several bug fixes and I will have some compatibility layers for some of the plugins. In the mean time, you should be able to update to 1.2.4 without any issues.

The Exceptions

The only exception here is that MooToosl More 1.2.4 includes a few plugins that are almost direct copies of what I have in 2.1.0, namely HtmlTable and Element.Delegation. If you’re using either of these scripts, you can just ditch the copy you get from me and use the ones in 1.2.4.

Harald Kirshner (a.k.a. digitarald) released the latest incarnation of his (awesome) flash / js based file uploader, FancyUpload.

Despite the delay, the completely rewritten version ofFancyUpload, version 3.0, got pushed to github today. This new version is more stable, has betterdocumentation and more showcases than ever. I even added two download packages with runnable installations, like many developers requested. This article introduces the new features and showcases, impatient readers can jump directly to the comprehensive project page or fork on github.

New Features

There are a lot of new features and fixed bugs in this new release, so let me distill the most important ones for you:

• The API with, separated uploader and file classes, allows an easy implementation in all kind of interfaces
• Events are dispatched for every step of the uploading process, to keep the interface as responsive as possible
• Progress tracks the loaded size, upload-rate, estimated time and other values for every file and for the batch as a whole
• File uploads can be stopped, restarted or removed anytime
• New Iframe-based class for multiple, asynchronous uploads without dependency on Flash
• Compatible with Flash 9 and 10 with the browse button as a transparent overlay or as an interactive image sprite
• Ability to change the upload URL and add POST/GET data on runtime, customized for every file or the whole process

Link »

In case you didn’t notice, MooTools 1.2.2 just launched along with MooTools More (1.2.2.1; were the last digit is the version of -more).

I’m working on a big update to Clientcide which I might get out tonight but it might take me a day or two to get it all together, so stay tuned.