MooTools

UPDATE: 1.2.4.4 is also released; there was a new bug in Tips introduced in 1.2.4.3 that was immediately patched.

This is mostly a bug fix release.

• Nearly 50 bug fixes (see the milestone for 1.2.4.3 in Lighthouse).
• Keyboard:
  • Added some support for just pressing ‘shift’, ‘control’, or ‘alt’
  • Added a bunch of keycodes for Mac compatibility
• Keyboard.Extras:
  • Support for “shortcuts” which are keyboard entries that have names and descriptions.
  • Also provides methods for listing all the active shortcuts as well as allowing a shortcut to be rebound (for instance, if you were to allow the user to choose a key for a shortcut).
  • Added a change event to Keyboard.manager whenever any keyboard is activated.
• Tips:
  • NEW Tips option “windowPadding” allows you to reduce or expand the virtual size of the window for tip positioning. Defaults to {x:0, y:0}. You can use that is a workaround for the scrollbars not being considered when calculating tip positions.
• HtmlTable:
  • fixed numerous bugs filed in Lighthouse
  • HtmlTable can no longer apply it’s click behavior more than once.
  • HtmlTable now pushes headers defined in the options.
  • Reworked HtmlTable’s DOM a bit to allow for positioning of the sort icon
  • Added new set method for headers and footers.
  • Fixed error in HtmlTable.Parsers when sorting by date. format(‘db’) was being applied to the text and not the date object.
• Array:
  • Added Array.shuffle
• Request.JSONP:
  • Made JSONP pass all arguments, not just the first, to its complete/success methods; see this discussion on the google group.
• Fx.Slide:
  • Added an option to specify the wrapper element for Fx.Slide. Was already present in the docs but could not be passed as an option.
• Mask:
  • Added options for the IframeShim for Mask

Download it with the MooTools More builder.

As usual, if you find any issues, file a ticket at lighthouse. There are already tickets open for 1.2.4.4 that we are not including fixes for in this release. Look for a release for these things in the next few weeks.

Users wishing to upgrade any large site from MooTools 1.1 to 1.2 can sometimes find it difficult. The API for 1.2 changed quite a bit, so without help upgrading your code can be fraught with danger.

Our solution is an upgrade helper that will allow you to replace your old MooTools 1.1 code with 1.2 code by logging deprecated methods to the console and telling you what needs to be changed.

The upgrade helper also attempts to automatically convert 1.1 calls to 1.2 calls. However, this helper is not really meant to be a compatibility script so much as a script designed to help you migrate your code. In almost all cases methods that have been deprecated or have had their API altered will provide feedback to the console when they are called. Ideally, developers will put this script into their environment with MooTools 1.2, use their application and change all the calls that throw warnings, then remove the upgrade helper from their environment.

Using the Upgrade Helper

You can download the upgrade helper on the MooTools Download Page along with current build of MooTools built for it. This companion library has all the functionality found in MooTools 1.1 (Drag, Accordion, etc. - some of these plugins moved out of MooTools Core and into MooTools More in 1.2).

Simply replace MooTools 1.1 with MooTools 1.2, include the upgrade helper, then include your site’s code. Browse your site with a browser that provides a console API (we recommend Firefox with Firebug) and take note of the warnings thrown (note, you can adjust the logging; see the readme). Address these in your code base until you cannot find any more, then remove the upgrade helper. You have now an upgraded website, and you can use the plugins in the Forge!

If you still have warnings after you have finished converting your code, have a look at the documentation for 1.1 and 1.2 and also the source code in the upgrade helper. Most changes are simple, but may require a change of arguments. There are a few breaking changes but in the vast majority of cases these should not affect you. A complete list of the changes between 1.1 and 1.2 can be found in the readme of the github upgrade-helper repository.

Feedback, Help, and Resources

The upgrade helper is being released as a beta for now. We’ve written and run tests against the browsers we support but the real world usage of MooTools will be the real test. As such, we hope that you, the MooTools community, will help us polish this script, by letting us know what features on your sites don’t work. Bugs can be filed using the github issues for the repository.

Arguably, this is something we should have provided long ago. Going forward, we’ve pledged to make all releases 100% backwards compatible for all documented methods and features.

Should you require any guidance or assistance, you can, as always, find us in the #mootools IRC channel or post in the MooTools Google Group.

Last of all, massive thanks to Nathan White and David Isaacson, for their early work on this. In the last few weeks the MooTools Dev team has spent a lot of time making and testing this upgrade helper, but these guys kicked this off with their contributions and they are most appreciated.

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.

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.

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.