Articles in the ‘Releases’ Category

MooTools Depender - A Build Tool for MooTools JavaScript Libraries

Written By Aaron Newton, on Monday, November 9th 2009, 2:10pm

As mentioned in the new features in MooTools More in 1.2.4.1, there’s a new plugin called Depender which uses MooTools dependency mappings to allow you to lazy load additional scripts on the fly based on what you need. Rather than list every single file you depend on, you just list the features you want to use and it computes all the specific files needed and each of the files that they need (and so on), excludes the files you already have, and then injects the remaining scripts into the document, providing a callback.

Unfortunately this method is rather slow. The JavaScript plugin must inject each individual script in the dependency list and all these requests can only go as fast as your browser can make them. As a companion to this plugin, we have also authored a stand alone server side application.

New Server-Side Depender

The new server-side depender companion app ships in two forms: a PHP version and a Django version. They each have their own positives and negatives. The PHP version ships with a web-based interface — a builder you can use to check off the things you want in your download (similar to what you see on MooTools.net). On the other hand, the Django version is faster. The Django app caches everything to memory but the PHP version caches results to disk.

Depending on your needs, you can also use these server-side applications to lazy load chunks of functionality on the fly. This obviously requires your application to talk directly to the server when it needs more code. These apps aren’t designed for enterprise scale.

The server side applications are available on github. We still consider the state of this project to be beta, but we want to get the tools into your hands now. If you have any feedback or find any bugs, we want to hear about it. Check out the documentation to see how it all works, including the Depender Client(docs), which gives you this nifty interface:

    Depender.require({
            scripts: ['DatePicker', 'Logger'], //array or single string for one item
            callback: function() {
                    //your code that needs DatePicker and Logger
            }
    });
    //later, you need to load more dependencies...
    Depender.require({
            scripts: 'Fx.Reveal', //array or single string for one item
            callback: function(){
                    //if, for some reason, Fx.Reveal is available already,
                    //then this function will execute immediately, otherwise it will
                    //wait for the requirements to load
                    $('someElement').reveal();
            }
    });

Libraries that you download with Depender will all have a standard header that looks something like this:

    //MooTools, <http://mootools.net>, My Object Oriented (JavaScript) Tools. Copyright (c) 2006-2009 Valerio Proietti, <http://mad4milk.net>, MIT Style License.
    //MooTools More, <http://mootools.net/more>. Copyright (c) 2006-2009 Aaron Newton <http://clientcide.com/>, Valerio Proietti <http://mad4milk.net> & the MooTools team <http://mootools.net/developers>, MIT Style License.
    //Contents: Core, Browser, Array, Function, Number, String, Hash, Event, Class, Class.Extras, Element, Element.Event, Element.Style, Element.Dimensions, Selectors, DomReady, JSON, Cookie, Swiff, Fx, Fx.CSS, Fx.Tween, Fx.Morph, Fx.Transitions, Request, Request.HTML, Request.JSON, More, Element.Shortcuts, Element.Measure, Fx.Reveal
    //This lib: http://clientcide.com/js/build.php?requireLibs=mootools-core&require=Fx.Reveal&compression=none

This header includes, among other things, a manifest of the contents of the file and a url that can be used to retrieve it again. This is especially useful if you want to come and download the file again for the latest version.

The builder on MooTools.net does not use Depender yet but we will deploy it there soon. You can see it live on the Clientcide builder.

MooTools 1.2.3 Released

Written By David Walsh, on Friday, June 19th 2009, 4:32pm

Today we give you what will likely be the final release of the MooTools Core before the jump to 2.0. While MooTools 1.2.3 is primarily a bug-fixing release, MooTools 1.2.3 also introduces an important new feature: Framework compatibility mode.

The value in making this change is allowing developers to use more than one framework within a page (which is NOT something we recommend or endorse, but we recognize this is not always under the developer’s control). Not relying on the dollar function prevents the need for jQuery.noConflict() when using jQuery and MooTools together, for example. If no other framework is detected, however, $ will be assigned to MooTools. This means that all of your current MooTools code WILL NOT break. It does, however, mean that if you want to use MooTools and jQuery together (without using jQuery’s noConflict mode), instead of using $ in your MooTools code, you’ll have to use document.id().

If you want your MooTools plugins to be cross-framework compatible, you’ll have to replace all the instances of $ with document.id().This change only applies if you’re using more than one framework on your pages. If all you use is MooTools, nothing will change for you. Look forward to more details about Framework compatibility mode in a future post.

MooTools Core & More Updates

While we encourage you to browse LightHouse and the histories for MooTools Core and MooTools More to get the most detailed list of changes, the following significant updates were committed in MooTools 1.2.3:

Core

  • Element: MooTools compatibility mode: the $ function is only defined if no pre-existing $ function is found. If an existing $ function is found, you can use document.id()
  • Element: changed internal instances of $ to document.id
  • Core: fix for server-side MS JScript 5.x; makes MooTools more friendly for server side programming
  • Class: Class doesn’t require Browser, removed from scripts.json
  • Element: Fixes for set/get Property
  • Element.Dimensions: fix for webkit body.scrollTop inconsistency, getBoundingClientRect used whenever possible (not just for Trident), renaming element.position to element.setPosition; adding docs for the method; alias is included in-line for compatibility
  • Hash: Hash extend no longer uses the window if no arguments supplied
  • Request: clearing Request readystate before calling success or failure;
  • Selectors: Added :enabled pseudoselector, was in the Docs but not implemented.
  • Docs: Fixed docs headers for first-child, last-child, and only-child.
  • Internal: UnitTester test suite is now a git submodule
  • Numerous small fixes, speed improvements, documentation tweaks, etc.

More

  • Per the change in -core, $ is no longer used (uses document.id instead)
  • Element.Measure: trying cssText solution for Element.expose (again).
  • Element.Forms: swapping feature detection for browser support per
  • Date: Massive refactoring of Date.js and Date.Extras.js
  • Drag.Move: Fixing drag with grid issues
  • IframeShim: altering zindex assignment in IframeShim to better ensure that it’s always underneath the shimmed element, updating Iframeshim’s empty document creation; fixes https issues in IE6
  • FormValidator: reworking formvalidator scroll-to logic to be a little more efficient
  • OverText: preventing overtext from focusing on inputs except when they are interacted with (so OverText.update() does not focus an input);now stops polling when elements are hidden (when polling is enabled)
  • Fx.Scroll: adding scrollIntoView method - scrolls an element so that it is completely visible; if below the view, scrolls down until it is at the bottom of the screen, if above, scrolls up until it is at the top.
  • JSONP: was calling (the deprecated) this.request instead of this.send during retries
  • URI: Adding set(‘data’, obj) to set
  • Assets: adding error callback for Assets.images
  • Tips: removing dependency for Element.Measure for Tips; updating CSS class name in OverText
  • Numerous small fixes, speed improvements, documentation tweaks, etc.

MooTools 2.0 is on the Horizon

As mentioned above, 1.2.3 is likely the last update for MooTools 1.2. MooTools 2.0 will introduce numerous performance improvements and new features. We want to stress that MooTools 2.0 will feature 100% compatibility with MooTools 1.2.x.

Thank You!

Thank you for the bug fixes, feature requests, and support during MooTools’ 1.* lifetime. You, the MooTools community, have helped make this framework better with every bug found and question asked on the forum. We look forward to releasing MooTools 2.0 this summer and getting feedback from everyone in this awesome community.

MooTools More 1.2.2.2

Written By Aaron Newton, on Tuesday, May 5th 2009, 5:51pm

Today we’re releasing a small update to MooTools More that address a few bugs and minor feature requests that cropped up after the initial launch. Briefly, these are the things changed since 1.2.2.1:

  • Removed debug statement that enabled IframeShim in all browsers by default
  • Fixed a few docs typos
  • Removed UTF-8 charset signature on String.QueryString and URI.Relative
  • Assets.image now have an onError option and handle image load failure more gracefully
  • FormValidator.Inline had issues displaying some of it’s validators when input values changed
  • OverText now allows you to specify the element type for the label test (defaults to “label”)
  • Fixed an issue with addRequests in Request.Queue; the arguments were reversed (addQueue still worked fine though)

None of these changes should affect your usage of the class, except, possibly, the change to OverText, as the element it previously created for the labels was a div. If you styled these with css and referenced the tag name, you’ll either need to update your css reference or pass in element: “div” as an option when you invoke the class.

MooTools 1.2.2 and the New MooTools More

Written By Valerio Proietti, on Thursday, April 23rd 2009, 7:53pm

Today we’re releasing two goodies for you: MooTools 1.2.2 and the new MooTools More (1.2.2.1).

Core

MooTools 1.2.2 is a mainly a bug fix release but it also includes an almost entirely new Class.js. The reasoning behind this is that the old Class.js didn’t play nicely with some advanced usages of this.parent() present in the new MooTools-More. We already had the script ready and tested in the MooTools 2.0 branch so we simply “backported” it to 1.2.2. Other than providing the parent fixes, the new Class also features a much more robust inheritance model, especially when dealing with objects.

For example, the objects you implement now in a class are merged if an object with the same name is found in the class prototype:

var Animal = new Class({
    options: {
        color: 'brown',
        says: 'hissss'
    }
});

Animal.implement('options', {says: 'meow'});

// Animal.prototype.options is now {says: 'meow', color: 'brown'};

This is especially useful when overriding default options in classes, such as Request.

Another object-oriented feature we introduced is that now sub-objects are actually inherited Parent-to-Child. If you implement a new option in Animal, then Cat, which is a subclass of Animal, will get the new option as well, and so will every instance already existing. An example:

var Cat = new Class({
    Extends: Animal
});

var kitty = new Cat();

Animal.implement('options', {nu: 'one'});

Cat.prototype.options.nu == 'one' //true
kitty.options.nu == 'one' //true

This obviously also applies to methods.

Additional changes to the MooTools Core in 1.2.2 are mostly minor bug fixes.

More

One of the new features of MooTools-More, since the last RC, is that it is now possible access the previous state of overwritten methods of classes through Class.refractor. An example:

var Cat = new Class({
    energy: 0,
        eat: function(){
            this.energy++;
    }
});

Cat = Class.refactor(Cat, {
    eat: function(){
        this.previous(); //energy++!
        alert("this cat has " + this.energy + " energy");
    }
});

This functionality allows users to integrate seamlessly with existing classes, and add to existing methods without the need to subclass.

We’re considering some way to make this behavior more generic for a possible inclusion in MooTools-Core 2.0.

The first RC of MooTools-More produced a lot of feedback and contributions that we’ve integrated as we prepared for our full release. Following this full release of the new MooTools More plugins, we’ll begin adding new features quickly and regularly with what we hope will be biweekly releases.

More To Love

Written By Aaron Newton, on Monday, March 9th 2009, 5:28pm

I know, sometimes when you look at the source code of MooTools you ask yourself, “How could this possibly be any better? Because it’s so awesome.” I am by and large always stumped by this question, as the code is so meticulously maintained by its authors.

Today, I have an answer. The only way to give you a better MooTools is to give you more of it. It’s that awesome. Today, we’re making MooTools awesomer.

We give you the new and improved MooTools More - the official plugin collection for MooTools. The plugins we are releasing today take the fifteen files previously in MooTools More and triple them. That’s three times the awesome!

(more…)