The main new adition is Class.Thenable which is a new Class mixin that can be used in Promise style flows by using its then method. When implemented in a Class, it makes the class "thenable" in the Promises/A+ sense of the word, meaning it can be used in Promise style flows by using its then method.

The implementation, however, is more than just a "then" method. Any instance of a Class implementing Class.Thenable is a Promises/A+ compliant object (generally referred to as "a Promise") with only one exception: it is possible to reset the Class's value resolution state fully (rejecting pending reactions, and starting empty) to support a Class instance living for longer than just the lifetime of one value resolution.

Example using Request:

var request = new Request();
request.send().then(function(response){ console.log(response.text); });

Example hooking into a native Promise:

var request = new Request();
var promise = Promise.resolve(request);
request.send();
promise.then(function(response){ console.log(response.text); });

You can find this new version 1.6.0 in the website or within the dist folder of the 1.6.0 tag (Core).

IE warning: This will be the last version to support old IE browsers. Next minor and/or major versions should be only IE11+ compatible. We might still release some patch in the 1.6.x version if needed.

Array.from deprecated, now called Array.convert: Following the conclusion of the ES6 specs we know now that Array.from will have a different implementation than the one MooTools uses.
Because of this we renamed Array.from to Array.convert to not overwrite the Native implementation.
We kept it as it was though in the compat layer for compatibility reasons if you really to use it still.

To keep the API consistency we changed also the name of the method in Function, Number and String Types.

The main changes in this release are:

• Rename .from method in Array, Function, String and Number (#2758)(#2760)
• New feature: Class.Thenable (#2743)
• Add Safari 9 to Sauce Labs tested browsers (#2749)
• Added ESLint to Grunt specs to keep code styled and clean (#2748)
• Gruntfile refactor (#2741)
• MooTools specs goes Mocha (#2737)
• Specs upgrade, refactor and cleanup. Huge specs cleanup by Tim (#2736)
• Fix so the legacy $pick gets exported to global (#2735)
• Fix so Event Class gets exported to global (#2733)

• Add extra aliases to Assets package's description (#1335)
• Added ESLint to Grunt specs to keep code styled and clean (#1327)
• New feature: new option keepOpen to Accordion (#1333)
• New feature: added sort order to onSort function arguments (#1332)
• Fix String.extras regex to not mix self closing tags (#1328)
• Fix validate-match "matchName" when containing spaces(#1186)
• Fix unDraggableTags in Drag (#1159)
• Fix to validate-reqchk-byname (#1329)
• New feature: added IPv6 compatibility to URI.regex (#1322)
• Fix semicolon in end of file that broke packager (#1319)

You can find the new version in the dist/ folder of the Github repo or on the website.

The main things in this release are:

• Fix "Unspecified Error" in IE when calling getSize() on a node that isn't in the DOM (#2648)
• fix IE version detection in old IE (#2653)
• Protect 'contains' method in Array prototype (#2654)
• Fix httpOnly cookies (#2676)
• Fix Garbage Collect typo in Element Docs (link)
• Fix mouseenter/mouseleave Readme where info was incorrectly placed below mousewheel (#2681)
• Fix camelCasing of -ms- prefixed properties in Element.Styles (#2686)
• Fix visibility when fade is chained (#2597)
• Fix event.key for keypress (link)
• Fix non-enumerables iteration in old IE (#2696)
• Move Object.keys to Core.js, upgrade for in loops (#2696)
• Add pageshow and pagehide events (#2701)
• Fix for typeOf ($family property), when a Class extends a Native Type (#2688)
• Fix mapping of shift onkeypress (#2703)
• Fix relatedTarget in mouseenter and mouseleave (#2697)
• Fix warning for input[type="email"] (#2705)
• Fix Microsoft Edge UA string support to Browser (#2716)
• Fixed broken links in docs (#2728)
• Fixed wrong offset calculation because of floating point values (#2437)
• Added tests for io.js and Node.js versions (0.10 and 0.12) for Mootools Server version (#2729)

• New feature: Class.Singleton (#1285)
• Fix tooltip to not show when empty (#1299)
• Added more Norwegian, Swiss, Argentinian translations
• Fix String.QueryString when converting + into spaces (#1313)
• Fix module definition of Drag, Slider, Sortables, and others to be consistent with others (#1311)
• Add touch events to Drag (#1292)
• Remove old callbacks in Request.JSONP.request_map (#1315)

In 1.5.1 we added a new dist/ folder in Core, present at the tagged commit, for those who want the Core source, as well as a needed update so you can get MooTools via Bower.

Worth a notice is also the new MooTools Packager. MooTools has always been about modularity, and for those of you that want to choose which modules to use you can now use the new MooTools Packager (for Node.js/Grunt), as well as the website builder. The new Packager allows to compile source files from the dependencies in the YAML header. You can find it on GitHub and NPM.

The main things in this release are:

• Mousewheel regression fix for Chrome and Firefox. (link)
• DOMEvent's wheel property now listens for DOM3 wheel event also. (link)
• IE8 iFrame leak fix. (link)
• Added postMessage to NativeEvents. (link)
• Fixed setter so IE7/8 can set text of style element. (link)
• Normalize values on newElement for radio and checkbox types. (link)
• Fixed svg element size. (link)
• Fixed getter behavior for border-radius. (link)
• Added fix for IE8 to be able to set html into style element. (link)
• Added option to trigger xhr.withCredentials without http auth. (link)
• Added the PATCH and HEAD methods to Request. (link)
• Fixed hasClass without classList to comply with ES6. (link)
• Added fix for IE9 when setting an input type to "email". (link)
• Fix for IE when removing delegated "submit" event from destroyed element. (link)
• Updates in Docs.

• Drag position calculation fix. (link)
• Form.Validator.Extras credit card regex update. (link)
• Fix Scroller Class to be able to use window as element. (link)
• Added custom sort function for HtmlTable.Sort. (link)
• Fixed Type error for empty string in Form.Validator. (link)
• Added onLoad callback for local and cross-origin CSS assets. (link)
• Fixed sort regex to respect sci-notated floated numbers in HtmlTable.Sort. (link)
• Fixed scroll miss-placement while dragging and scrolling. (link)
• Updates in Docs.

More stable and well tested than ever

1.5 is a HUGE bug fix release with roughly 240 commits addressing new browsers that have entered the market as well as new features in the JavaScript language. The team spent a ton of time instrumenting the tests to run against Travis CI and Sauce Labs so that the source code would be easier to test. This will help to make new contributions, fixes and features to the framework and release much more rapidly.

It's easy to underestimate the value of all the work that went into the project over the past two months.

It works as follows: there is an issue on GitHub. You, or anyone else, can create a bounty to back the issue. Then some developer (either a MooTools Team Member or some other contributor) fixes the issue. Once it gets merged and he or she can collect the bounty!

We think this could help to prioritize issues and to increase community contributions. After all, who doesn't like to get some pocket money to buy a beer or MooTools t-shirt!

But before we can do that, we need your help. We've set up a form so we can gauge interest in a MooTools Conference. All you need to do is take a minute and answer the questions.

We'll keep the form up until next week, but make sure you answer quickly so we can start planning this awesome Official MooTools Gathering (or OMG--which might or might not be the name of the conference).

It was late 2009, the MooTools Forge (plugin repository) was just released, and I was learning JavaScript and MooTools by creating many plugins. This is already the first form of contributing to the MooTools project: releasing code that might benefit others. The cool thing about this was that I also helped other people on GitHub that released their MooTools plugins, and thanks to this interaction I learned even more.

At the same time the MooTools Core developers were building MooTools 1.3. I closely followed the developments and noticed that a few things were still missing. One thing that seemed easy was the documentation. So, in some spare time I dove into the MooTools source code, looking through the commit history to see what changed, and update the existing MooTools 1.2 documentation accordingly. If I remember correctly a pull request on GitHub at that time was basically a private message to the MooTools devs, so it was exciting whether my changes would be accepted. Fortunately contributing to the documentation is always helpful, so my changes got merged!

Because MooTools 1.3, at that time, was fully under construction, there were many loose ends that were easy to fix. I got invited to talk to the MooTools devs on IRC, and got involved more and more. So I started working on MooTools More 1.3, which was something else that was not updated for the new 1.3 release. This was a great way to learn how the internals of MooTools work: we had to look into MooTools Core to know how to effectively update the More code, or even fix things in MooTools Core, but at the same time it wasn't too difficult yet.

Later that year I went to the MooTools Hackathon in London, where we finalized the MooTools Core 1.3 and More 1.3 releases which were released later that year. I also got a nice place on the MooTools developers page!

So how does my nice story tell you how to contribute? Basically what I did is look if something was blocking the release for MooTools 1.3, went ahead and fixed that, just by spamming the MooTools devs with new pull requests.

The most important point is direct communication with the developers. This mainly happened on IRC, but is still valid. Join #mootools, say you want to help out with something, or did something, explain again why we should merge your pull request. This is really the best way to get started. If you don't directly see a loose end where you can help, the MooTools developers probably know something interesting for you.

Currently there are a few aspects where you can help. If you have followed the development on GitHub you might know about prime, elements, agent, moofx etc. There is still some stuff (especially website/documentation related) to be done for a real release. See also the roadmap on the Prime Wiki. But it's also perfectly fine if you like to work on the current version of MooTools Core. The idea is to release a MooTools 1.5 with mostly bugfixes, and a few deprecations. The biggest chunk of work for 1.5 is a review of bug reports and pull requests.

If you're not really comfortable contributing code or documentation directly, writing blog posts, tweeting about MooTools or helping other people on the MooTools Mailing List, #mootools on IRC or stackoverflow are really great ways to contribute too.

I would like to conclude with the benefit of contributing to MooTools or Open Source in general. I've learned so much and you get the opportunity to do things right. Apply testing techniques, try new technologies, learn more than you want to know about IE7 or other interesting browser behaviors. The things I learned by contributing MooTools simply made me a better developer.

Edit: we created a wiki to collaborate on design and websites for MooTools projects on GitHub. So if you're into that kind of thing, this is another great way to contribute!

Firefox 18 already ships this new version of contains. This is not a problem for MooTools 1.3.x and onward, but this breaks MooTools 1.2.5, especially the code inside the MooTools framework that utilized this method, like selectors.

This new 1.2.6 release solves these issues by overwriting the native version with the MooTools version of String.prototype.contains.

For the next MooTools version, 1.5, we will use the standard ES6 version. If you rely on the old behavior (which is only when you use the second argument), it will be possible to use the old version through the compatibility layer.

• Download 1.2.6
• Or upgrade to 1.4.5
• See changes on GitHub

Découvrez Mootools - Un framework JavaScript pour des sites dynamiques et interactifs (Discover MooTools - A javascript framework for dynamic and interactive websites) is aimed at beginner and intermediate developers who wish to create spectacular effects using MooTools. This book does not go deep into topics that would likely only confuse you, but instead it keeps everything simple and provides many clear cut examples and illustrations that will facilitate your understanding. Priced at 12.5 Euros (~15$) it’s a must-have if you’re looking to learn MooTools.

As the author says, it does not cover the entire framework. Instead, Xavier Lecomte selected the most commonly used MooTools pieces and explains them in detail. Throughout this book, you’ll learn how to create classes, handle DOM elements, create AJAX requests and create effects using Fx classes. The latter is probably the most discussed topic of this book as it goes through almost every Fx-based class in MooTools. When it comes to Fx classes, the most complex part is probably options. Although they are well named, they could be difficult to grasp, especially to the novice user. This book makes this type of functionality very clear by explaining all the options for each class discussed, at times, through the use of illustrations. The Fx chapter wraps up with a complete example, where the author builds a pong game using tools explained throughout the chapter.

Finally, the book discusses work done by the MooTools community. Although it does not go deeply into each project (most of them would require a book on their own), it gives a good idea of what MooTools is able to offer.

To conclude, if you're a native French speaker interested in learning MooTools, this book is a must-have, especially at that price. I hope Xavier Lecomte will continue writing about MooTools, the in-depth detailing of this book is amazing and will certainly benefit many.

iOS 6 Theme

Android Theme

Transitions

Simulator

The Boiler Plate

Moobile.Component.defineAttribute

The Future

Requests

Moobile is developed by Jean-Philippe Déry and is hosted on moobilejs.com

This operating system had just such software, in a number of different variations. One of these created the “illusion” that the observer was travelling through space, passing stars. This is the subject of this week’s challenge.

The good news is, you can optimize MooTools builds to remove specific (IE) code! Packager has been used to concatenate builds since MooTools 1.3. Removing certain code blocks, like MooTools 1.2. compatibility or specific IE code is one of the features of Packager. Lets see how it works. We begin with downloading Packager.

One of the most common requirements of web applications is to be able to respond to user input, and in particular clicks (or touches). Continuing with our theme of element generation (and in some cases animation); this week’s challenge will be to create a basic whac-a-mole game.

The problem with these kinds of questions is that they often speak of the over-dependence on a certain framework (such as MooTools or jQuery) without a proper understanding of how JavaScript works or how to structure code well.

It is with this in mind that we want to set some challenges in plain old JavaScript (which are probably good programming challenges for any language) that will flex your grey matter.

Moobile is a mobile web application framework built on MooTools. It focuses on building mobile apps that behave as close as possible to their native counterparts, either on a mobile browser or on a webview wrapper such as Phonegap.

Moobile is also meant to be extended. I believe one of the strengths of a mobile web app is the ease of creating something entirely different. Moobile helps in this area by providing a structure as well as controls, view and controllers that can be easily extended to suit your needs.

1.4.5 brings a critical bugfix for Fx.CSS which caused many troubles for tweening and morphing your element styles. The bug was caused by a fix in 1.4.4 which should improve animating other length units like % or em (see #2160. Many of you noticed the bug and filled bugreports and also helped us testing this new release.

We have improved our tests and are planning to freeze the code for a new release for a longer period so we can gather more feedback to prevent potential regressions. If you're interested in testing a new release in your application, you can ping us on IRC (#mootools on freenode.net), Twitter (@mootools / @astolwijk) or in the MooTools User Group.

We recommend that all users upgrade to 1.4.4 as soon as possible.

###What is JxLib JxLib is a JavaScript UI framework built on MooTools. It allows web developers and designers to quickly build user interfaces for their applications. JxLib is based on some sweet HMTL markup and strives to be fully CSS compliant. It is also a modular library allowing you to pick and choose from the available components as well as giving you the ability to override default behaviors and extend core classes.

All well-written web sites / apps that are interactive have the same basic pattern:

If you're a plugin owner, you can subscribe by going to your plugin page and clicking 'subscribe by email' at the bottom.

Remember, if you find a bug in a plugin, you should always report it in that repository's Github Issues.

As it stands, all comments will need to be moderated before they appear, just to make sure we don't get trolled / spammed and we're really looking forward to adding the ability to comment to the other parts of the website - particularly in documentation.

Thanks to Aaron for making this happen!

Upgrading from 1.4.0 should not cause any backward incompatibilities. We recommend all users to update to 1.4.1 as soon as possible.

• Download MooTools Core 1.4.1; Build MooTools Core 1.4.1
• Fork / clone MooTools Core 1.4.1 from GitHub, and build it yourself with Packager.
• Google CDN (will be updated soon)
• Browse the Documentation for Core & More.

Especially the additions for milestones and assignees were important for us. With this in place GitHub issues can finally replace Lighthouse.

This recap includes:

• Mentions
• Answers to: Where do you guys think MooTools can improve?
• Sneak Peak to Improved Docs
• Agenda for July 19th Dev Hour

This recap includes:

• Compare 1.3.x and Experimental 2.y.x Code Diffs
• Things to Come (Agenda’ed Office Hour, Dedicated “Hackathon” Office Hours)

• MooTools 2.0 Community “Wish List”
• MooTools Documentation
• Flex Box Model
• Require.JS and Namespacing
• MooTools Roadmap
• MooTools Feature: Accessors
• Model Change Events
• MooTools 2.0 Site
• MooTools UI and Mobile
• Event Delegation in Core
• Github Issues

This is a reminder that tomorrow (June 21st) we’re having another office hour and you’re cordially invited to join us.

Unlike last week, this week we’ll have a couple of questions ready to steer the conversation. This week we’ll talk about MooTools 2.0 and what you guys need to love MooTools even more. We’ll be taking names down as well, for those that would like to contribute.

Keep reading to learn the details.

A new component has been added to MooTools More: Table. Table was slated to be added in MooTools Core 2.0, but we're making it available in MooTools More now. Table is similar to the JavaScript object literal, but where an object can only have a scalar value (string or number) as a key, Table can have any value as a key. Where the order of values in an object is not static like an array (by specification, usually browsers keep the order which they are defined), the values in Table will have a static order. These advantages come with a performance cost, where an object value is a direct look-up, Table uses indexOf which is less efficient, so use with care.

• Fixed Slick bug with ~div-like selectors
• Fixed MooTools in the Node.js environment
• Fixed an exception in DOMReady in Chrome when the page with MooTools was in an IFrame
• Fixed setOpacity for very small numbers in IE
• Fixed an exception in FireFox 4 when MooTools tried to overwrite document.head
• Added the possibility to create elements with boolean values with an selector, e.g. new Element('input[checked]');

• Rewritten Element.Position which solved some issues
• Added Table, as described above
• Ironed out some Event Delegation issues
• Additional fixes can be found at the Lighthouse for 1.3.2.1

• Download MooTools Core 1.3.2; Build MooTools Core 1.3.2
• Build MooTools More 1.3.2.1
• Fork / clone MooTools 1.3.2 from GitHub, and build it yourself with Packager.
• Read the Core commit logs to see precisely what has changed.
• Read the More commit logs to see precisely what has changed for More.
• Browse the Documentation for Core & More.
• Please report any bugs you can find on Lighthouse, our bug tracker.

One of the items that came up several times in the survey was a desire for more support for internationalization. MooTools More already ships with a system for localizing plugins, but this functionality isn't baked deep into the framework. Several comments in the survey implied a desire to see this functionality available throughout MooTools Core. One respondent wrote, "It is difficult to understand MooTools as my English is not great. My website has many visitors from where I live and they need all to understand it. Thank you."

You asked for a more culturally sensitive framework and we listened. Given that the MooTools development team is based all over the world from Italy to Austria to The Netherlands to Germany to Sweden we can understand the value of having MooTools available in your native tongue.

• Lots (and by that I mean LOTS) of documentation improvements, clarifications and cleanups
• Updated Slick to 1.1.5 and improved the speed of our Slick selector engine
• Added delegation support for submit, focus, blur, reset, change and select events in MooTools More
• If available the native JSON methods are now used in JSON.decode and JSON.encode
• Multiple Pseudos click:relay(a):once (demo)
• Two new pseudo events: :throttle and :pause
• Added String.truncate to String.Extras in More
• More than two hundred changes to increase the stability of both Core & More

I am also pleased to announce our newest addition to the MooTools More team, Jacob Thornton, who is a great developer, currently working for Twitter. He has put a substantial amount of work into making MooTools More even better.

Be sure to check out the updated demos in our new demos section.

• Download MooTools Core 1.3.1; Build MooTools Core 1.3.1
• Build MooTools More 1.3.1.1
• Fork / clone MooTools 1.3.1 from GitHub, and build it yourself with Packager.
• Read the commit logs to see precisely what has changed.
• Browse the Documentation for Core & More.
• Please report any bugs you can find on Lighthouse, our bug tracker.

Most of you think MooTools Core is fine as it is, with an obvious exception: Swiff has to go. This change has already been planned for the next major release. There are several good ideas about what we could add to Core: element shortcuts (.hide() and .show(), for example), a few Types from MooTools More, Event Delegation, Pseudo Events, and cowbells! In short, we would like to keep MooTools Core a compact, modular, object oriented framework. Specific UI plugins, for instance, would be a better fit for MooTools More or maybe the Forge.

Many of you supplement MooTools Core with MooTools More (96%) but are also equally divided whether More should contain UI plugins or if those should be in the Forge. Most of you (60%) like to see more abstraction APIs, such as enhancements to Core. That’s probably why Types and Drag are the most popular More components. HtmlTable is the biggest candidate for removal (43%) followed by Accordion (34%) (ndVP: yey!). In general, you had many ideas about what to add to MooTools More, such as specific UI plugins, support for HTML5 features, geolocation, and storage.

The Forge is pretty popular, about 65% of respondents use the Forge to a find plugin. About 11% have contributed to the Forge with new plugins. Respondents shared great ideas for improving the Forge, including: comments, ratings, better search, featured plugins or a combined (packager-web) download page which selects all dependencies.

A very important part of MooTools is the online API documentation. Most of you think they are pretty good, but are also put off by the lacks of examples. We’ve heard you and that’s why we responded with our fancy new demos which we released a few weeks ago! Our plan is to add new demos which we will use as additions to the docs. You will find links from the docs to the demos, which you can play with thanks to the jsfiddle integration. We don’t have demos of each part of Core or More yet, so if you want to help, you can fork the repository and add new ones, or just ping us (@astolwijk or @fakedarren) with new jsfiddles. Another popular idea that we particularly liked is the addition of a comment system to the API documentation.

I’d like to point out that you can easily start hacking on the docs if you feel so inclined. Just make sure you have a github account, fork mootools-core or mootools-more, browse to the Docs folder and select a .md file. Github has awesome online editing features, so you can work without knowing anything about GIT! If you modify a file we will see it via the network view and will include your fix into the main repository.

We are really happy to see that the release of MooTools 1.3 went smoothly and most of you are already in love with the new MooTools. One point for improvement would be to put the upgrade tutorials on the wiki in a more prominent place on the mootools.net website.

Congratulations to the lucky winner of the awesome MooTools t-shirt. You’ll receive it shortly, and we sincerely hope you’ll wear it with pride!

In conclusion, thanks for all the "MooTools FTW!" responses, the cowbells suggestions, and other great feedback you guys sent us. We <3 you.

So! Check out our new demos. We hope you like them!

We're also delighted to be able to include full jsFiddle support, so you can easily view, edit and generally play with our new demos easily!

The entire demo runner is also available on our GitHub repository; so if you can run PHP it should be super-simple for you to get them up and running.

Do you have any demos you think we should add? Let us know in the comments! Or, fork it, and send us a pull request :)

We love our new demos and hope you do too!

The community and the MooTools users are very important for MooTools and its development. Therefore we would love to hear who you are and how you are using MooTools. You could do this by this survey. It will take about five minutes and none of the questions are required.

The purpose of this survey is to help us prioritize what the development team spends its time on. We want to make MooTools as useful for you as we can. Some questions are more explicit than others, relating to where we put things or what features we should focus on more or less. Armed with this information we can dedicate our resources to the things that matter most to you.

Because we think your opinion is valuable, we'll be giving something in return. You can win a MooTools™ Shirt. Maybe you will look just as awesome as Tim soon!

The survey will be open for two or three weeks. After that time we will compile some sort of conclusion from the results and share it with you.

So head over to the survey and let your opinion count!

Update: I've just closed the survey. A huge thank you for the awesome responses!

Awesome new features? What awesome new features?

With the help of our two newest developers, Arian and Tim, the MooTools More team has been working hard to get More up and running with Core 1.3. Aside from updating old Core API calls, they've been fixing a lot of the Lighthouse bugs, as well as providing new improvements like Event.Pseudos, Locale and more.

The last of the 1.2.x More releases has been a priority since the Core 1.2.5 release. It will come with a lot of bug fixes and a few new features. The hold up is converting all of More's tests to use the new process described below. As such, it looks like More 1.2.5.1 and More 1.3.0.1 will likely be released together.

To help with this increased development—and to make sure less bugs squeak by—we have set up a new testing environment using the wonderful Windmill testing framework. An example of the new sandbox environment can currently be found at http://review.mootools.net:9876.

A couple of us have also been hard at work improving the testing throughout all the MooTools projects, but you'll just have to wait and see the awesome details in a later article.

With the release of GitHub's new Pull Requests system, we've found that they fit very well into the MooTools development workflow. The new system makes it easier for the developers to review pull requests, and makes the discussions associated with them public.

Because the MooTools community is made up of awesome developers who are more than happy to share their work and to give back to the project, we realized that this new pull request feature could be very helpful in accepting contributions from the community. As such, we are encouraging all of you to send us your pull requests for review and possible inclusion in the Core and More repositiories.

We hope that you're as excited as we are with what's cooking on the MooTools development front. We'd like to hear your opinions, comments and suggestions in the comments section below, so don't hesitate to drop a line or two.

We also invite everyone to visit our official Github repository and drop by the official #mootools IRC Channel on Freenode. MooTools also has a twitter account that you can follow for more news and updates.

And stay tuned—we have something very special coming in the next few weeks that will hopefully blow your minds.

Now off for a chocolate milk!

• Fix for fireEvent under IE9 beta.
• Forcing MooTools bind implementation to work with the latest gecko / webkit beta browsers.
• Fixes HTML Elements creation in IE9 beta.
• Fixed Elements garbage collection in IE.

Or, if you prefer, you can have a look at the actual code diff.

Documentation has been updated accordingly and many new Specs have been added.

As usual, you can quickly download it or build your own version.

Keep an eye out for the 1.3 release in the following days!

On Elements, theres only 3 getters/setters that you need to worry yourself with: get/set, getStyle/setStyle, and store/retrieve (we'll ignore getProperty for now).

The most commonly used are Element#get and Element#set. They will first check the Element.Properties object to see if a specific getter/setter exists, before defaulting to getProperty or setProperty. So for instance, you can get the href of a link, or you can get the text of an element, which will get the node value in a cross browser fashion.

<a id="myAnchor" href="/blog">Blog</a>
<div>All my <span>text</span></div>

$('myAnchor').get('href'); // '/blog'
$('myDiv').get('text'); // 'All my text'

You can do as you would expect with the setters in the same way.

$('myAnchor').set('title', 'MooTools Blog'); //sets title attribute
$('myDiv').set('text', 'other text'); //sets the innerHTML

For now, let's just look at the other methods, and we'll take a look at how this works later so you can add to it yourself.

The other commonly used pair of methods are Element#getStyle and Element#setStyle. These should hopefully be self explanatory. Their benefit is that they normalize certain styles the browsers are inconsistent about, such as opacity.

Let's take a look at an example that MooTools itself defines. The style property is easier to remember and read than using cssText, so that's what MooTools does for us.

Element.Properties.style = {

    set: function(style){
        this.style.cssText = style;
    },

    get: function(){
        return this.style.cssText;
    }

};

Seeing how the style object is setup, you can easily create your own. Given a Person class, and the given HTML, we could decide it would beneficial to be able to get the instance of a Person from an element.

<div class="person person_3">
    Sean
</div>
<p>Hello</p>

Say we were to want to get a Person instance when we have this element. We would define the property on Element.Properties.

Element.Properties.person = {

    get: function() {
        var id = this.className.match(/person_(\d+)/)[1];
        if(id) return Person.getById(id);
    },

    set: function(person) {
        this
            .addClass('person')
            .addClass('person_'+person.id)
            .set('html', person.name);
    }
};

Now we can use our familiar get and set methods.

$('TestPerson').get('person'); // returns Person instance of ID 3.
$('OtherTest').set('person', new Person('John')); //turns the paragraph into a person
// <p class="person person_4">John</p>

The third pair of methods that MooTools defines for elements is Element#store and Element#retrieve. Woah woah woah. What? You're telling me you can get properties, and you can retrieve them? What the heck guys?

Don't worry, it's pretty easy to know and understand the difference once I explain it. get and set are the most common methods, and default to element attributes, like I said. In many other places, such as when you use el.get('tween'), the MooTools teams made the getter call retrieve for you. You've been accessing it, without knowing it.

OK, great Sean. Why should I care how you give me the values?

I hear you. You see, most of the getters/setters are used to access attributes. But what happens you want to get at or set some other kind of property. What if you want to set an actual object, or a function to the Element. I guess you could JSON encode and create a custom attribute, but that's not good practice. And you lose out on any class info of the object, in case it was an instance of something.

These methods also help with an issue that arises when you try to store something like an Event object or an instance of something else that refers to the Element in question. Certain browsers don't handle the circular references that well if you were to set el.prop = { someEl: el }. It can leave nasty memory leaks.

If you really want to know, behind the scenes, MooTools keeps a storage object that is totally separate from any element. Every element created gets assigned a unique id, and that id is used as a key on the storage object.

Regardless, you don't have to do anything special for store/retrieve to work. Using our above example, it would work like so:

$('TestPerson').store('person', new Person('Sean'));
$('TestPerson').retrieve('person'); //returns the exact same Person instance

These two common pairs of methods actually have a third method that relates to each of them, which allows the destruction of each respective data location. These methods are Element#erase and Element#eliminate.

This all sounds great, I'm sure. Now when you're writing your own classes and plugins, you can be sure to use the pre-packaged properties. However, it's much more powerful when you can find a useful property to add that relates to your own plugins.

Sean McArthur is a software developer at Blazonco.com who is madly in love with MooTools. Most of his contributions involve sharing tips and information about MooTools (and programming in general) at his blog and on Twitter.

Most notably we have removed the dependency on Hash. If you build 1.3 without compatibility you won't get the Hash object no more. But fear not, we have added Object.js which brings you all the Hash methods as generics. Everything else is really minor, has to do with stability or was meant to improve code quality (we really take this seriously).

We are trying hard to provide you with a consistent and meaningful API so we have decided to introduce one tiny tweeny minor breaking change. If you were setting tween, morph, load, or send options using the getter (element.get('tween', {...options here...})) that will not work anymore. You will have to use set(element.set('tween', {...options here...})), as get needs to be a pure getter.

All in all the new beta is faster, better, more stable - in a word - sexier. Tell us how it works for you.

• Download the built 1.3 beta 2 release.
• Fork / clone MooTools 1.3 from github, and build it yourself with Packager.
• Read the commit logs to see what has changed.
• Wondering how those amazing new methods are called? You can browse our markdown documentation right on github.
• And don't forget to report any issue you find with the beta, compatibility or not! The more reports we get, the fastest we'll have a final release.

Thanks to everyone who helped polishing the 1.3 release. I would really like to thank Arian Stolwijk (@astolwijk) who has contributed significant improvements to the documentation.

Fx is not just for animating elements

In a recent project I worked on with Thomas Aylott the page did some calculations and displayed the result after the user pulled some sliders around. Rather than just change the text from one number to another, the element would increment the number before the user's very eyes. With a fun interface like that, they had no choice but to apply for a new credit card right then.

Admittedly, I may not have thought to extend Fx to do something like that. After all, the first line of the docs for Fx is: "This Class will rarely be used on its own, ..." My first thought would be to use a periodical with a counter and then set the text until the counter was done. But Thomas extended Fx instead. Though it's the base class for all animations (tween, morph, scroller, etc.) its methods can be used for all sorts of abstract "animations."

For this article I've just come up with a few potentially useful extensions of Fx to get the idea across that you can use it for more than just element animations.

Essentially Fx just calculates a sequence of values between two numbers. The options kick in to make those values more interesting. This class, Fx.Log, simply updates the text of an element every step of the effect. Notice that this class is essentially the base Fx class except for the tiny set method.

Here's another demo that visualizes all the visible options of Fx. After you draw the effect, hover the dots to see the exact value calculated (or view source and see them all together.) Playing around with this demo might tell you more about how Fx works than anything else out there.

By default, Fx uses 50 fps. So every second it'll kick out 50 different values and fire the set method 50 different times. For the next few demos I only wanted to do something if the rounded value is different than the last rounded value, so I came up with Fx.Diff. If the value is different, it'll call the render method.

Fx.Diff = new Class({

    Extends: Fx,
    count: 0,
    render: $empty,

    set: function(now){
        now = now.round();
        var diff = now - this.count;
        if (diff) {
            this.render(diff, now);
            this.count += diff;
        }
        return this;
    }

});

Since this appears to be no different than the very first demo, we'll just look at the code. Note, the difference is that the first counting demo would change the text in the element every single frame (50 times a second), but this code would only change it if the new rounded value is different from the last.

Fx.Count = new Class({

    Extends: Fx.Diff,

    initialize: function(element, options){
        this.element = document.id(element);
        this.parent(options);
    },

    render: function(){
        this.element.set('text', this.count);
        return this;
    }

});

I can actually see myself using this one somewhere:

Notice that Fx.Typewriter overwrites the start method of Fx. The Fx start method takes two arguments, from and to. The usage for Fx.Typewriter is to simply pass in a string of text like so: myFx.start('A whole bunch of text'). This new method knows the from argument is always 0, splits up the text into an array (one item per character) and then uses that length as the to argument. After that logic is done, it simply calls the parent start method. Then the render method takes over by figuring out how many characters to display, filtering out the tail end of the array, joining what matters, and finally setting the text of our element.

There's a very creative effect called Fx.Text on the forge. It's an animated text replacement effect. I think it's really cool and does a great job of extending Fx.

This next script is far too magical to simply show you the code. You'll need to view the source for this beauty.

Ryan Florence is a MooTools enthusiast and contributor. He maintains his JavaScript focused blog, MooDocs.net, and moo4q. Follow him on twitter or checkout his plugins on the Forge.

To protect ourselves and the MooTools community, we've started two physical screening programs (or "meetups"), one in London and the other in the heart of Silicon Valley.

In a surprising turn of events, both groups have had very informative meetings in which actual people have shown up, allowing us to conclusively state that at least some of the members of the MooTools community are, in fact, human. Insightful discussions were had by all, new users and advanced developers alike.

If you're in the Bay Area or London, it is imperative that you attend at least one of our screening sessions, to verify yourself as human. To be notified about future meetups, as well as voice your opinion on when/where they should be, you can join the Meetup.com group for your area:

• MooTools London
• MooTools Bay Area

Anything Interesting to Share?

If you have something insightful and MooTools-related to share, and think you can spin it into a fifteen minute presentation, please let us know.

Right now, we don't have any formal communication set up, but it shouldn't be to hard to get in touch with either Darren (London) or myself (Bay Area). Contact information can be found on the developers page.

Thanks for using MooTools, and we hope to see you there!

The main class you need to concern yourself with is the Form.Valdiator class itself which provides methods that apply specific rules to inputs to see if they are valid. You can then choose how you want to inform your users that they need to address these problems, but that's not the job to Form.Validator (though it is the job of Form.Validator.Inline, which we'll cover in a bit).

Let's talk little bit about the rules that are applied. Form.Validator allows you to define rules that test the state of an input and return true or false - true if the input passes the validation rule, and false if it doesn't. Here's a simple example:

Form.Validator.add('doesNotContainTheLetterQ', {
        errorMsg: 'This field cannot contain the letter Q!',
        test: function(field){
                return !field.get('value').test(/q/,'i');
        }
});

The above code adds a global validator that allows you to assert that the input doesn't use the letter Q. The arguments are the validators' key and then an object that contains an error message to show the user should they encounter the error, and a function that is passed the input as an argument. This function inspects the value or, really, anything you like, and then returns true or false.

The key you give your validator is important. At any time you can validate a field against any validator by using this key as a reference by doing:

myFormValidator.test(key, input[, warnOnly]);

The first two arguments are the important ones here; the key of your validator and the input to test. Where things get interesting are when Form.Validator does this for you. By giving your input that key as a css class name, you tell Form.Validator to validate that field with this validator. In this manner you can quickly and unobtrusively decorate your inputs with the requirements and validate the form. If something goes wrong with your JavaScript, your form will submit as normal. Here's a really simple example:

The alerts aren't pretty, but you can see how our validator is now applied when you submit the form.

Form.Validator ships with several validators listed in the documentation. These include simple stuff like required that just validates that the user put something - anything - in the input. But there are also validators for email addresses, only letters, dates, urls, etc. The key is you can write your own - you don't need to wait for us to release something for you to make use of it. There are an extended list of validators in Form.Validator.Extras that include some edge cases. Things like validating that two inputs have the same value (like an email verification for example).

It's also possible to configure validators with data unique to the input. For example, let's say you want to have an input with a minimum length validator - the user must type in at least 5 characters. You could write a validator called minimum5 or whatever, but then you'd have to duplicate it for any other character length. For this purpose, Form.Validator allows you to assign values to the input, like so:

<input type="text" name="username" class="minLength:10" id="username"/>

These values - the 10 and 100 values in the example above - get passed along as JSON decoded values to the validator. Here's what that looks like:

Form.Validator.add('minLength', {
    errorMsg: function(element, props){
        return 'Please enter at least {minLength} characters (you entered {length} characters).'.substitute({minLength:props.minLength,length:element.get('value').length });
    },
    test: function(element, props){
        if (props.minLength != null) return (element.get('value').length >= props.minLength;
        else return true;
    }
});

As you can see, the error message (which in our previous validator was just a string - the message) can also be a function which is passed the input and then any properties defined in the HTML. The fact that the message can be a function allows you to include information not only about how the validator is configured but also other information, like some aspect of the value the user actually entered. The test is also passed along these p roperties of course which allows you to make the properties a condition of the test. We could, in theory, rewrite our doesNotContainTheLetterQ validator to accept an argument about the character (or, better yet, characters) that we want to disallow:

Form.Validator.add('doesNotContain', {
    errorMsg: function(field, props){
        return 'The value you input cannot contain any of the following letters: ' + props.doesNotContain;
    },
    test: function(field, props){
        if (props.doesNotContain)
            return !field.get('value').match(new RegExp('[' + props.doesNotContain + ']', 'i'));
        else return true;
    }
});

Note that the properties defined have to be JSON decodable, so you can't have your input like this:

<input type="text" class="doesNotContain:qz"/>

Instead you'd have to quote the string:

<input type="text" class="doesNotContain:'qz'"/>

Here's our example:

The base Form.Validator class comes with a plethora of options and events. You can configure it to validate inputs whenever they change (on blur), or to only show one error at a time (serial). You can tell it to ignore hidden fields (those that are not visible, there's no point in validating inputs with type="hidden") and disabled inputs. There are numerous useful methods that let you run the entire validation routine on the form (.validate()), reset all the errors (.reset()) or validate / reset a specific field (.validateField() and .resetField()). You can pause the validator and resume it (.stop() and .start()) as well as ignore / un-ignore a specific field (.ignoreField() and .enforceField()) and more. There's even an element method that lets you validate a form (Element.prototype.validate).

Now that we've covered the basics of how Form.Validator works, let's consider the fact that our examples so far have been rather ugly (who wants alert messages?). MooTools More ships with a default implementation that smoothly displays messages inline, right after the input: Form.Validator.Inline. This class is the "pretty" version of Form.Validator but don't think of it as the only game in town. You can easily implement your own "pretty" version without a lot of effort. If you want to put errors in a popup or fade them in over the entire screen or play a sound it doesn't matter. The base Form.Validator class is there for you.

Looking at the Form.Validator.Inline implementation, you'll find all the same options and methods from Form.Validator along with a few extras that control how your messages appear. For instance, by default, the validation rules show up immediately after the input. This requires a bit of forethought in how you structure your HTML. If your input is inline with something else (like a submit button), validation errors are going to change that when they appear (because they are divs, which by default are block level elements).

The only real option that Form.Validator.Inline has to offer is whether or not to scroll to errors (useful if your form is long and will likely cause the user to scroll to the submit button). Here's a simple example, building on our previous one:

As you can see, the error message slides in, but it breaks our layout a bit. Let's do some CSS work to make this look a little nicer.

It's not The Sistine Chapel but it does look nicer. Our error doesn't appear to break our layout anymore either.

As a final example, I'll show you a version that extends Form.Validator.Inline to put the validation messages in tips that popup pointing at the input. Here's a demo:

If you want you can check out the source on github and download it with its dependencies on Clientcide.

Overall the purpose of Form.Validator is not to be the only solution for displaying validation messages to your users, but rather a flexible solution for client side form validation on which to build. You can extend it and manipulate it to display messages in any way you choose - and you should!. The default "pretty" implementation - Form.Validator.Inline - is just one way to use the class. In my opinion Form.Validator is one of the classes in MooTools More that shows off the power of MooTools' object oriented design, allowing for a great deal of flexibility and reuse.

Thanks to Lloyd for suggesting this edition's topic. If there's a plugin in MooTools More you'd like me to focus on next time, by all means, make a suggestion in the comments.

Aaron Newton is a contributor to MooTools and the principal developer of MooTools More. He is the author of the book MooTools Essentials as well as the Mootorial online MooTools tutorial. He posts (rarely these days) at his blog Clientcide.com and (much more often) on Twitter as anutron. He works for Cloudera, (which is hiring, by the way).

Anyways, here's what's new:

MooTools 1.3 moves away from the $name functions. Most of the useless ones, such as $chk (god knows why I thought it was a good idea to have $chk), were completely nixed. Some of them moved to the proper object's namespace ($merge » Object.merge, $pick » Array.prototype.pick). Some others were renamed without the stupid $ in front ($type » typeOf, $defined » nil). In the end, there are a lot less global variables now. You can refer to the 1.3 documentation to have a proper list of what's changed. Keep in mind that the old version of the methods will still work, by default. There will be a way in the future to "compile" MooTools without the compatibility stuff, but the feature is not ready yet.

Every native type has now a from method that will try to convert every object passed to that type. Array.from, for instance, replaces both $A and $splat. Function.from will return a function that returns the passed in value, if it wasn't a function itself. String.from... well you know that at this point, don't you? We also changed how we internally handle Native types, but that should be none of your concerns, since they were handled with private apis anyways.

It is now possible, easy, and even perhaps recommended to generate MooTools (and its plugins) yourself. Last few months I've been working, on and off, on a pretty advanced projects-builder. It's called Packager, it supports multiple project dependancies and has a very similar syntax of what's used in the Forge right now. It's written in php and you can use it from your php webpages to dynamically include JavaScripts for development, or you can build a single .js for production from the command line.

If you care to build MooTools and MooTools projects for yourself, you should take these steps:

1. Clone MooTools 1.3b1.1 from github.
2. Clone whatever other Packager-ready MooTools project from github (color, table and touch, for instance, are my Packager-ready plugins).
3. Clone Packager itself from github.
4. Read Packager's README. Pretty much everything you need to know is in there.

Ofcourse, Packager itself is not limited to MooTools, MooTools plugins or just javascript projects. A tutorial post on how to use Packager for development is coming soon (few years tops).

If you dislike php, worry not! There is also a Django builder, called Depender, written by our Aaron Newton, on github as well. I really don't know how it works, as I don't do python, but I do know it's scope is way greater than that of Packager. Depender can, for instance, dynamically build your MooTools for production use, like that. But don't take my word for it, go check it out on github.

The most notable new feature in 1.3 is Slick. Slick is our new, shiny, super fast, exhaustively tested, pure-javascript selector engine. There will probably be a dedicated Slick post in the following days (or months, given our relaxed release cycles), but here's a few Slick-facts for those who haven't checked it out already:

• Slick is a MooTools-family project by MooTools developers Thomas Aylott, Fabio Costa and yours truly. It can be forked from github, free of charge!
• Slick is an incredibly advanced evolution of our previous selector engine.
• Slick is written using only pure-javascript, none of the MooTools apis are required. It can be used in any project or framework, and it does not require MooTools to function (though the MooTools DOM components do require Slick).
• Slick is speedy, blows away the 1.2 selector engine by 50%, at least. We will give you detailed data in the post dedicated to Slick.
• Slick supports every selector you can think of. Seriously, every one of them. I promise you.
• Slick is customizable, you can make your own pseudo-selectors, your own attribute-selectors, and many more your-own kinds of things.
• Slick supports reversed combinators. You might not know what they are, but they are pretty darn cool.
• Slick has a detached parser. You can parse a css-style-selector string and get back a property-filled object.
• Slick perfectly supports XML documents.
• Slick is slick!

On another note, thanks to the Slick's parser, you will be able to build an element using a css selector. Let me give you an example of this cool new feature (courtesy of our amazing Christoph Pojer):

new Element("input", {"id": "someID", "class": "someClass1 someClass2", "disabled": true});

new Element("input#someID.someClass1.someClass2[disabled=true]");

As I get back to work on an exciting number of totally amazing upcoming MooTools projects that you know nothing about because you don't follow me on github, I'll leave you with a few useful 1.3 links:

• Download the built 1.3 beta 1 release.
• Fork / clone MooTools 1.3 from github, and build it yourself with Packager, or Depender.
• If you want a full changelog, go read the git history, you lazy bastard. Changelogs are so 2001.
• Wondering how those amazing new methods are called? You can browse our markdown documentation right on github.
• And don't forget to report any issue you find with the beta, compatibility or not! The more reports we get, the fastest we'll have a final release.

UPDATE: There was a "merge" problem with beta1, so we quickly fixed it and re-tagged beta 1.1.

Have fun with 1.3! I know I will.

Valerio

If you ask me how I did I'd say I missed a few connecting ideas but got the concept out there and got some people thinking. Several people came up to me afterward asking how to actually give this a shot on their web apps. Also, if you are reading this on a Mac, do this: command + option + control + 8 (⌃⌥⌘8). I think for the first time in the history of OSX this keyboard shortcut was useful. The projector had a hard time with my bright colored code on a black background so I inverted the the whole presentation!

Some of you have read my post Pigs take flight about using the Class module from MooTools to write modular code in a way we all love but use jQuery for DOM manipulation, effects, AJAX, etc. That was the basis of my talk. You can find the slides and a demo at my blog here.

The Demo is especially awesome.

It was very well attended, said to be the largest JavaScript conference ever. There were a lot of really talented people there and all of the speakers did great. I am humbled by the ability of the jQuery team to put together great events and market their library, I'd even say a bit jealous!

It seems at the user level people see frameworks as rivals or something, but at the framework developer level they generally feel like we're on the same team, working to make the web better.

There was a lot of talk about organizing code, which is a problem that jQuery doesn't try to solve. I don't think any other framework can step in quite like MooTools to do it and yet keep the jQuery API in tact when writing an application's code (thanks to mutators). Another testament that -core is rock solid and ridiculously versatile for JavaScript generally, not just the DOM. I also found that a lot of people didn't know that you can create custom builds of MooTools to solve all sorts of JavaScript problems.

So, thanks jQuery for a great weekend!

• Slides and Demo
• Pigs Take Flight Blog Post
• jQuery Conference 2010 SFO

At FOSDEM we ended up hanging out with the Dojo crew. We like them; they are always doing interesting things and their framework is one that we've always looked at and said to ourselves, "If we ever needed feature X we'd probably just port it from them." Anyway, at FOSDEM a group of their developers and ours got together and started brainstorming about closer ways to work together. Since then the discussion has gotten closer and closer to where we are now.

Starting today the Dojo and MooTools projects will begin merging and joining forces. Part of this is to share resources - more hands coding makes more code, right? But part of it is, well, we'll be frank, we're kind of tired of reinventing the wheel. We love the solutions in MooTools, but at the end of the day, the API is all that matters. It doesn't matter how you detect that the DOM is ready, so long as when it is your code runs. The same could be said for selector engines, XMLHttpRequest, and a whole host of other things. What this means in practical terms is that we just don't have to do as much work and, to be frank, after 4 years of working on MooTools, we're happy to cede some of the more tedious tasks to Dojo. Sure, their architecture isn't quite the same (or maybe even as good) as ours, but it works. This will free our development team's time to work on their own projects and maybe start getting paid for it, which brings us to the second point.

For the past four years we've been writing code and releasing it for free. In our talks with the Dojo team we all agreed that all this free time donated to anyone who happened to want our work just wasn't quite worth the hassle. Don't get us wrong, writing the code is fun, but it's all the other stuff. The bug reports, the hand-holding in the forums and on IRC, the constant demand to "compete" with other frameworks (whatever that means). It just sucks the pleasure right out of it. We find ourselves burning nights and weekends to write code for strangers to use and it gets old.

Going forward, the code base will continue to be free, but access to the documentation will require a small "donation" (we'll probably set a really small minimum, like, say $.25) - frankly, the documentation has gotten too good to be free (we contemplated printing it and just selling it as a book, but micropayments is much more "Web 2.0"). Filing bugs will still be free of course. But we're working on a system that lets our users put money towards the bugs they care about the most. The bug with the most money donated gets our time and gets in the next release. We think this will cut down on both the number of bugs we get but also help manage expectations. If you have a bug that you think is important, you either need a lot of people to agree with you (which they will if the bug is really broad) or you need to pay a lot (in which case it's like you're hiring us as freelancers).

What will we do with the money raised? We'll probably start sponsoring more meet-ups and sending more people to conferences, but we'll also be able to compensate the developers who bring you all this great stuff. Certainly no one can argue with that.

As we begin merging functionality we'll likely retire large portions of both frameworks. MooTools has a great effects library while Dojo has a lot of solid widgets. MooTools ART will likely get shelved in favor of dojo.gfx, Dojo will likely drop it's effects libraries in favor of MooTools' effects which are really nice, much of MooTools More will either be retired (in favor of existing Dojo widgets) or turned into Dojo widgets themselves, etc.

For backwards compatibility we'll be implementing the "donation" system as well. For the portions of the MooTools and Dojo cores that are deprecated we'll allow the users to prioritize which parts we offer compatibility for. Same goes for effects, plugins, etc. We hope this new model will encourage businesses that use our awesome frameworks to recognize the value we bring and to compensate us for our time.

If you have any questions, post them in the comments below. Comments are still free - we haven't implemented the "donation" system for them yet, either.

Update: Yes, this was an April Fool's joke. We love Dojo and that whole team... but not that much.

I've seen stuff like this:

fn1(fn2(10, fn3('house')));

Hard to figure out what's happening. Instead you can write code like:

fn3('house').fn2(10).fn1();

I've used this in a couple scripts, it takes a number and returns a string with zeros padded in front: 123 becomes '000123'. Really handy for filenames and the like. Here's the ugly version:

function zeroPad(num, zeros){
  zeros = zeros || 3;
  var str = '' + num;
  zeros.times(function(){ str = '0'+str; });
  return str;
};

// usage
doSomething(zeroPad(document.getElementById('myInput').value, 3));

Number.implement({
  zeroPad: function(zeros){
    var str = '' + this;
    zeros.times(function(){ str = '0'+str; });
    return str;
  }
});

// so that it works on both numbers and strings
String.implement({
  zeroPad: function(zeros){
      return this.toInt().zeroPad(zeros);
  }
});

// usage
$('myInput').get('value').zeroPad(3).doSomething();

doSomething(zeroPad(document.getElementById('myInput').value, 3));
// vs
$('myInput').get('value').zeroPad(3).doSomething();

Awesome? Yes. You can do the same thing to:

• Array
• Function
• Number
• String
• Hash

Some say extending natives is a bad idea. Personally, I think it's awesome--but this topic is a sore spot for some. Extending natives is a feature of javascript itself that any general application framework like MooTools is entitled to use. There could be an entire article dedicated to this topic but this article isn't it. This article is simply here to show how to use this handy feature.

Arian Stolwijk created this amazing gem: Array.Math. Code samples often tell the story faster:

[2,5,1,6].sum(); // 14
[2,5,6,2].product(3); // [6,15,18,6]
[9,12,15].quotient(3) // [3,4,5]

This is all made possible by extending the Array native, see?

Array.implement({

        sum: function(start,length){
            var sum = 0, 
                start = start ? start : 0,
                length = length ? length : this.count()-start;
            length = start ? length + 2 : length;
            for(var i=start;i<length;i++) sum += this[i];
            return sum;
        },

        product: function(p){
            var arr = $type(p) == 'array';
            return this.map(function(entity,i){
                return arr ? (entity * p[i]) : (entity * p);
            });
        },

        quotient: function(q){
            var arr = $type(q) == 'array';
            return this.map(function(entity,i){
                return arr ? (entity / q[i]) : (entity / q);
            });
        },

        // and a whole lot more awesome ...

    });

• this is the number or string, or whatever, when inside the method.
• Return something that makes sense (usually this).
• You can implement several methods all in the same code block.

This is just one more great tool to help keep your code organized and readable.

Most of you probably know the two document methods getElementById and querySelectorAll; because if you do, you understand how we select elements with MooTools methods. For those of you that don’t, you provide an ID string of an element in to getElementById, and a CSS selector string to querySelectorAll. The functions $ (which is an alias to document.id, see this post on Dollar Safe Mode for details) and $$ are basically equivalent to getElementById and querySelectorAll, respectively. Of course, since it’s MooTools, they’re more than that.

The dollar function, if given a string, will basically call getElementById on the document. If passed an element, it will just return the element, and if you pass an object with a toElement method, it will try to convert it to an element (we’ll explore that more a couple sections down). A key difference you’ll find between MooTools’ dollar function and jQuery’s is this: MooTools’ $() will only ever return 1 Element, and it will return null if no matching element is found. This means unless you’re absolutely 110% certain the element will exist, you’ll need to check the returned value before starting to call Element methods on it.

var loginEl = $('Login');
    if (loginEl) {
            loginEl.fade('in');
    }

The MooTools Team prefers two separate methods for the selecting elements; to remove any doubt about what a certain function call may be returning, we have one method for individual elements and another for multiple elements. In this case, it’s preferable to be explicit, instead of relying to ambiguous auto-magic. When we see $, we expect an element if it exists. When we see $$, we expect an array of elements (which, as you know, an array can always be empty). The double dollar function has some neat tricks that are explained in its own section below.

All this talk about Elements, but only about how to select them. MooTools also provides an excellent Element construction API.

With vanilla JS (mmm, vanilla…), you’d use document.createElement whenever you wanted to create and add a new element to the DOM. MooTools tries to make the JavaScript API more pleasant to use; part of that is a more consistent and easy to use syntax and part of it is using more Object-Oriented programming practices. It feels a lot more OO when creating objects using the new keyword, whereas the standard way is more procedural.

It turns out that every element you could create inherits from the Element prototype. Specifically, the elements you create through document.createElement would be HTMLDivElement, or HTMLParagraphElement, or whichever element you create. Like I said, they all inherit from the base Element prototype, and then HTMLElement, and so on. MooTools extends the base Element class, so that all elements receive some MooTools love.

MooTools augments the Element native, providing a super-duper sweet constructor. You can provide the tag name, and then an object of properties to set on the new element. The returned object is of the same type as the $ method mentioned above. The properties you can set are fairly extensive, so check out the documentation to learn more about them, but here’s a demonstration.

The dollar method provides another function: converting the instance of class into an element(-al?) form. This is similar to a toString function, which converts objects into strings when needed. You can define a method in a class called toElement, and return an element to “represent” the instance. Let’s take a look at a snippet from a Person Class:

Several extensions in MooTools More take advantage of this, like Form.Request, Form.Validator, HtmlTable, and others. And many plugins in the Forge use this approach as well. This means that after creating an instance of one of these classes, you can just hold on to the instance in your code. Whenever you want to affect the element that the instance is controlling, you just use $(instance) to retrieve it.

Aaron even cooked up a ToElement mixin, and wrote a bit more about this over here.

I pointed out earlier that $$ returns an array-like object containing Elements. It actually returns an object called exactly that: Elements. Behind the scenes, MooTools gets an array of all the elements that meet the selector (so it's still an array), and then extends the array with all the Elements methods. Why would we want that?

All the methods that MooTools adds to the Element native are added to the Elements class as well. You can do some pretty nifty chaining because of this. First of all, you don’t have to check that it didn’t return null. This is because any method you call on Elements, will loop through the array and try to call the method on each individual element. Even with an empty array, the loop won’t cause an error. And any method you call that would normally return a value, will return an array of the values from each element. An example should make this clearer:

//assigns a click event to all A tags
    $$('a').addEvent('click',  function(e) {
            e.preventDefault();
            alert(this.href);
    });  

    //gets all divs with an id set, and then returns
    //an array of the IDs  sorted alphabetically
    var ids = $$('div[id]').get('id').sort();  

    //gets all divs with a UL immediately inside
    //and assigns a class name to  the divs
    $$('div > ul').getParent().addClass('has-list');

While you could put together long chains acting on all the elements you’ve selected, I’d advise against this. It certainly looks cool, and will work fine one or 2 methods out on the chain. But every method call will cause another loop through all the elements. If you’re doing a lot of things to every element, you might as well do it all in a single pass. I’ll show you what I mean.

//this would loop through each time at addEvent, addClass, and fade
    $$('li  a').addEvent('click', function(e) {}).addClass('alertable').fade('in');  

    //whereas this will only cause 1 loop
    $$('li a').each(function(link)  {
            link.addEvent('click', function(e) {
                     alert(this.title);
            });
            link.addClass('alertable');
            link.fade('in');
    });

Still, when doing something simple, you can skip the each call, since Elements will handle that for you.

MooTools provides a lot of expressive power when working with the DOM. It's consistent API makes it a snap to add events, change styles, create elements and more. The object oriented nature of its implementation makes it so that you can extend Elements for your own purposes. Look forward to my next post where I'll talk about extending Elements in various ways and cover best practices for when you decide to bend Elements to your own will.

Sean McArthur is a software developer at Blazonco.com who is madly in love with MooTools. Most of his contributions involve sharing tips and information about MooTools (and programming in general) at his blog and on Twitter.

12 Steps to MooTools Mastery

Jacob Thornton's NetTuts article, 12 Steps to MooTools Master, is a high-level introduction to the MooTools JavaScript framework. The informative article touches on such MooTools topics as Mutators, Prototypal Inheritance, custom events, binding, and more. This tutorial probably isn't for the complete beginner, but is a good place to start for people still relatively new to MooTools and those considering it for the first time.

http://net.tutsplus.com/tutorials/javascript-ajax/12-steps-to-mootools-mastery/

Meio.Autocomplete

Meio.Autocomplete is the latest plugin from MooTools Contributor Fábio M. Costa. Fábio's class is packed full of options and events, making it one of the most flexible MooTools Autocomplete plugin available. Great work Fábio!

/forge/p/meio_autocomplete

DynamicTextarea

DynamicTextarea is a MooTools class that resizes TEXTAREA elements as the user types. DynamicTextarea boasts numerous options and events for maximum control over chosen TEXTAREAs.

/forge/p/dynamictextarea

Array.Math

Array.Math is an outstanding set of Math methods you can add to JavaScript's native Array object. Need to find the sum of numbers in an array? Need to normalize elements in an array? Need to get the vector length of an array of numbers? Be sure to download Array.Math! Kudos to Arian Stolwijk for his excellent work!

/forge/p/array_math

LazyLoader

LazyLoader is a unique MooTools plugin created by David Chan which allows you to defer loading of MooTools classes until they are needed. This is especially helpful when building large web applications. LazyLoader is very easy to use and implement.

/forge/p/lazyloader

Locate

Locate is a Geolocation plugin authored by Christopher Beloch. Christopher's plugin taps into the power of HTML5 and offers a few useful options and events to control the Locate instance.

/forge/p/locate

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your plugins in future posts!

MooTools Core ships with three AJAX modules, two of which include element methods (Request.JSON, the third module, doesn't alter the Element prototype). Request.js provides the Element prototype with a send method that lets you post a form (as in, $('myFormElement').send([request options go here])), and Request.HTML.js provides the Element prototype with a load method that lets you replace the contents of any DOM element with text returned from a server request (as in $('myElement').load([request options go here])). I use these fairly often, though I probably use the Request and Request.HTML constructors just as much if not more. But in my own work I found myself needing the combination of these two things; I want to submit the form and load the response into a DOM element. Turns out, I do this all the time.

Part of writing idiomatic MooTools code is encapsulating functionality into Classes. As I've posted before, I do this with almost all the code that I write. The only code that I author that isn't a class (or a static object) is a DomReady statement that instantiates classes. So when I have a pattern as clear as this - submitting a form and updating the DOM with the response - it's time to write a class.

Form.Request, unlike Request.HTML, is not an extension of the Request class (that's why it's not Request.Form). Because it is not a Request.HTML instance, it has a reference to an instance of Request in it. Form.Request's options include a requestOptions object that gets passed along to this instance so you can configure it however you like. By default, Form.Request derives as much as it can from the form element itself. It gets its URL from the action property and the method from the method property. The user submits the form and it cancels the submit event. Form.Request inspects that event to see if the user clicked a button and, if so, sends the name/value of that button along with the data like a regular form submission. Finally, it provides an extraData option so you an send along key/values with the form in addition to those in the inputs that the user fills out.

When the form returns a response, it handles it pretty much how Request.HTML handles any other response. It injects the HTML and evaluates any scripts in the response (this is an option, too).

And what about what we set out to do? To provide a method for Element that is the combo of load and send? The plugin provides the Element prototype with a formUpdate method that works just like those two methods combined (as in $('myForm').formUpdate({ update: $('myTarget') }), which sends the form and updates $('myTarget')).

Here's a simple demo to play with. Note how our html is plain old vanilla web 1.0 form stuff. Nothing fancy. And our JavaScript is dead simple (to get the default behavior).

Hmmm. Well, our behavior here leaves a little to be desired. The main thing that seems to be missing is any indication that something is changing - that the form has been submitted and we're waiting for a response from the server (MooShell provides a 2 second delay on the response to simulate normal web latency). We could add an event to our instance to tell the user that something is going on, like so:

Here's where the fact that this plugin is part of MooTools More comes into play. MooTools More includes a plugin called Spinner. I'll talk about it in depth some other time, but in a nutshell, it puts an Ajax indicator over an element that's being updated. It integrates with Request.HTML and Form.Request configures it for us. This happens automatically (unless you disable it in the options) and all we have to do is skin it. In this example, I've moved our message (that we're sending the submission) into the Spinner options.

This magic happens without much effort for us so long as we have Spinner.js in our page. This is the default behavior. We don't even have to specify the message text if we're content with just the spinner image.

One other thing Form.Request integrates with (also in the MooTools More library, naturally) is Form.Validator. That's another plugin I'm not going to spend a ton of time describing in today's post - we'll save it for a later post as it has lots of nifty things in it. But, basically, Form.Validator (and its subclasses) provide instructions for users who are filling out a form on the fly. Form.Request integrates with it so that you don't have to do anything to make them play nice together. Both intercept the submit event and both prevent its default behavior (i.e. sending the form), except that the Form.Validator class only stops it if the form is invalid. If Form.Request didn't respect this privilege, it would send our form even if the Form.Validator stopped the default submission event. To get them to cooperate, all you have to do is create an instance of Form.Validator on the form. Example:

In this example, we set a minLength value for our form (50 characters). The default html in the textarea is only about 45 characters, so if you just hit submit you'll see a red error message show up. Add some more text to our example, hit submit, and the error winks out and our form sends just as before.

One last trick up our sleeves here; you can append results instead of overwriting the contents of our target. Think of a to-do list kind of interface, where adding a value adds a new item to a list. To get this behavior, we just substitute Form.Request.Append into our example. There are some additional options; by default it uses another MooTools More plugin, Fx.Reveal, to smoothly transition elements into view. You can also specify if the item is appended to the top or the bottom of the container. Example:

So that pretty much covers Form.Request. I hope you find it as useful as I do. If you find it useful and fun, post a link in the comments showing off what you've done with it. In my next post I'll pick another plugin (or plugins) to dig into and show off their capabilities. If there's one you'd like to learn more about, post a suggestion for my next post in the comments.

Aaron Newton is a contributor to MooTools and the principal developer of MooTools More. He is the author of the book MooTools Essentials as well as the Mootorial online MooTools tutorial. He posts (rarely these days) at his blog Clientcide.com and (much more often) on Twitter as anutron.

I'm really excited and pleased to announce that my presentation "MooTools as a General Purpose Application Framework" which I delivered at the FOSDEM is now available on YouTube.

If you are not able to watch the HD-Version you can download the slides here.

Thanks again to the FOSDEM team for inviting me and for giving us such a big platform to present the MooTools project. If I could name one thing that I miss already about Brussels I would certainly say the waffles...

If you enjoyed this presentation and you want me or another developer from the MooTools Core Team to present at your conference feel free to contact us.

MooTools Driver for Rails 3 Helpers

Rails 3 has been recently been released with the new capability to create your own javascript helpers; no longer will you need to use PrototypeJS. Kevin Valdek has created a MooTools helper so that you can use your favorite javascript framework with your chosen Ruby application. Kevin mentioned that his release isn't complete at this point so feel free to contribute! Great work Kevin!

http://kevinvaldek.com/mootools-driver-for-rails-3-helpers

Moodit

MooTools now has its own Reddit topic. Be sure to share your favorite MooTools posts with all of your friends via Reddit!

http://www.reddit.com/r/mootools/

Moodoco

Moodoco is a purely web-based client-side MooTools documentation generator with HTML5 offline capabilities created by Lim Chee Aun. It uses the GitHub API to fetch all the Markdown documentation files from the repository and stores them offline in localStorage.

http://github.com/cheeaun/moodoco

MultiSelect

MultiSelect is a MooTools plugin from Blaž Maležič that turns your checkbox set into one single multi-select dropdown menu. This highly inventive plugin is a great way to make your select boxes much more appealing.

/forge/p/mutiselect

Mif.Tree

Mif.Tree is a flexible tree-generation plugin that loads trees of information from javascript objects. You could, for example, output a JSON representation of a directory and view your server via HTML/javascript trees.

/forge/p/mif_tree

Featured Blog: Ryan Florence

Ryan Florence's blog has been doing an outstanding job of explaining complex MooTools concepts. Be sure to check out his blog!

http://ryanflorence.com/

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your plugins in future posts!

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.

Aaron has written an extensive review about MooTools in 2009. I expect 2010 to be an even better year for our Framework. As a first step we would like to invite you to meet part of the MooTools Team at the FOSDEM in February in Brussels where I will do an interesting talk about MooTools as a General Purpose Application Framework.

The real strength of MooTools, however, is you -- the community. Here are a few of the many great MooTools plugins that were released during the month of December.

PassShark

Created by MooTools contributors Luis Merino (@Rendez) and Nathan Querido (@nfq), PassShark duplicates the iPhone's method of password masking. A great method for making your passworld fields a bit easier to use.

• PassShark on the Forge
• Blog-Entry

MooPix

MooPix is not only a MooTools slideshow function but a method for accessing your public Flickr photos. Though no server side scripting is required, MooPix remains very small.

• MooPix Website

Notimoo

Notimoo is a simple Mac Growl clone made with MooTools. At only 4KB Notimoo is a lightweight but still provides the right amount of customization.

• http://www.paquitosoft.com/notimoo/

MGFX.Tabs 1.1

Sean McArthur has recently updated his popular Tabs class by making it more efficient and more flexible.

• MGFX.Tabs 1.1 on the Forge
• Blog Post and Demo

Fx.TransMorph

This Plugin by Lim Chee Aun (@cheeaun) allows a different transition for every property that is being animated.

• Fx.TransMorph on the Forge

Other Stuff Worth Mentioning

• Webkit Gradient Creator (double click to create new pins!)
• Scroll Clock
• MooTools FormValidator Tutorial
• Offline MooTools Docs Generator
• HTML5 Audio Player with MooTools
• WTFramework? 2.0 (must-have bookmarklet)

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your plugins in future posts!

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.

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.

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.

Today we're introducing a tool that has been in the works for the past few months that we believe will change how our community collaborates forever. Meet the MooTools Forge.

The Problem

As a framework, you probably expect MooTools to be compact and provide you with the tools that solve most of your JavaScript problems easily and elegantly and that's been our goal all along. But for all the other specific needs that your projects have, no matter what framework, you've probably found yourself googling for plugins or snippets before. No one wants to reinvent the wheel.

That Google search will probably return thousands and thousands of results. Many people have even approached the same problem in many different ways (try searching for a mootools slideshow plugin!). This distributed model, although relatively effective, represents problems for both users and developers.

For the users, it becomes hard to establish comparisons between the plugins as every developer will represent them differently on their websites. Sometimes it's hard to find a demo, sometimes you just don't know how to use the thing. Other times the website will be offline for a couple hours, or maybe you don't know on what other components the plugin might depends to function.

But can we blame developers? Creating a plugin that you can distribute to people takes work. And for some of us, experience shows that writing documentation, uploading it to our cumbersome blog systems, preparing screenshots (and then upgrading them upon a new release!) can sometimes be even more difficult than writing the plugin itself. Still, there are some good reasons to consider releasing your code.

The Solution: for users

For people trying to find plugins, we wanted a simple interface with visual focus on what's available. Going through lists of plugins whose names are not always that intuitive or descriptive is both boring and inefficient. You might find yourself opening dozens of tabs just to see what the plugin can potentially offer. We want to try and put all the information you need to make a choice right in one place.

While each plugin can have tags that you can browse, we also came up with a concise list of categories that group the most recurrent functions: Effects, Forms, Interface, Media, Native, Realtime, Request, Utilities, Widgets.

For plugins themselves, we wanted to make three basic tasks easy: seeing a demo, downloading, learning how to use. This is the result:

We believe it's important as well to know who is behind the scenes. To see who is that guy or girl that spent the time to create that amazing piece of functionality that impressed your clients or boosted your website usability. As such, the MooTools Plugins repository comes with simple to tools support to allow you to stay in touch.

The solution: for developers

We're very proud of how straightforward and efficient we've made it for developers to add plugins that:

• look great
• specify dependencies
• have descriptions with syntax highlighting
• are easy to maintain

We decided to integrate with GitHub, the social coding website, to enable developers to focus on the code and nothing else. By following a few simple guidelines, you'll be able to deploy code to the source control repository (git), and then only click one button in our website: either the one to add it, or the one to update it.

In the following video, I'll show you how I create an account, upload my plugin, and then update it in 30 seconds.

Conclusion

We hope you like this new website feature as much as we do, and we look forward to your involvement and contributions.

As an user of the system, if you see something off or have a suggestion, please drop us a note.

As the developer and maintainer of the project, I want to give my special thanks to Chris (for his help with Markdown parsing), Oskar (for his design help) and the Symfony project, for providing us with a great framework to build on, as well as the entire MooTools development team who helped find bugs and provided countless suggestions on how to make it better before we launched it.

But the plugin repository itself wouldn't be anything without you - the MooTools Community. As much as the plugins catalog is for you, it must by definition be by you, too. As excited as we are to have this finally online, it doesn't compare to our excitement to see what our awesome community comes up with every day.

On another note, the technology that empowers the Forge has been opensourced, for the use of any other open source project.

Happy hacking!

Significant progress was made on MooTools 2.0. Additionally, we will be releasing a 1.3 version shortly, which will include some of the awesome stuff from MooTools 2.0, so you can get your hands on it a bit quicker.

MooTools ART also was given some love. One sticking point has been that Internet Explorer does not support the <canvas> tag but now thanks to Simo Kinnunen (sorccu) we have a VML adapter so we can push on with this development. We can now combine this with the work Aaron Newton has done with Cloudera and we should be able to launch a beta in the coming months. We're really excited by ART and hope you are too.

Another way we want to improve the MooTools experience is by adding demos to the documentation, particularly for some of the UI components in More. The Mootorial has always been a fantastic resource and thanks to Piotr Zalewa (zalun) and the awesome MooShell we are now beginning to prepare embedded examples in our documentation. We're writing some great snippets and demos and you can expect to see these appearing on our documentation pages over the coming weeks. We really love MooShell and the team have some great improvements to this valuable tool almost ready, including user accounts and versioning. Keep your ears peeled for a blog post with more details soon!

Next year we hope we can organize similar meet-ups that you, the users, can attend. We certainly intend to hold one in London in the spring, and are discussing other venues across the world. We're really excited by the prospect of being able to meet people face-to-face and hope that some talks and workshops are something that the community want.

We also want to give a big thank-you to Abacus e-Media for hosting the event. Here are some pictures of the dev team at work:

• http://www.nathanquerido.com/
• http://picasaweb.google.com/christoph.pojer/LondonHackathon
• http://www.flickr.com/photos/zalun/sets/72157622853461134/show/

Look forward to an exciting announcement about the Forge which is currently in private beta -- your treasure trove of MooTools plugins will be here in time for Christmas.

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.

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, <https://mootools.net>, My Object Oriented (JavaScript) Tools. Copyright (c) 2006-2009 Valerio Proietti, <https://github.com/kamicane>, MIT Style License.
    //MooTools More, <https://mootools.net/more>. Copyright (c) 2006-2009 Aaron Newton <http://clientcide.com/>, Valerio Proietti <https://github.com/kamicane> & the MooTools team <https://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.

MooShell

MooShell, created by Piotr Zalewa (zalun), is the best code pasting tool since Pastebin. MooShell allows you to paste your HTML, CSS, and MooTools javascript into the page and test. MooShell is an excellent utility for troubleshooting an issue or demonstrating your code.

http://mooshell.net/

Up The Moo Herd IV: There's A Class For This

MooTools contributor Mark Obcena keeto continued his excellent series of "Up the Moo Herd" tutorials with "There's a Class For This." This post discusses Class Mutators, Mixins, and MooTools' inheritance model. Consider this post a must-read for novice and expert MooTools developers.

http://keetology.com/blog/2009/10/27/up-the-moo-herd-iv-theres-a-class-for-this

MooRTE: The Mootools Rich Text Editor

MooRTE is a great MooTools rich text editor. MooRTE is lightweight, customizable, and very easily skinnable. Try MooRTE out in your CMS!

http://siteroller.net/projects/moorte/

Call to Upgrade: MooTools 1.1.2 and MooTools 1.2.4

Remember to upgrade your MooTools 1.1 and MooTools 1.2 builds to 1.1.2 and 1.2.4 respectively. Firefox 3.6 has removed document.getBoxObjectFor which will impact Gecko detection.

/blog/2009/11/02/upgrade-mootools/

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your plugins in future posts!

Today's release offers no new features, a lot of very minor fixes (to docs and the like), and the restoration of a few changes to the API that weren't intended (Tips and Fx.Slide, in particular).

MooTools Search Beta: /search

This enhanced search has been integrated with the MooTools documentation and will help you easily navigate and identify information in the documentation better than the previous documentation search. The new search system also searches multiple domains -- this will allow you to find MooTools demos, forum posts, tutorials, screencasts, and anything MooTools-related. Initial supporting domains include MooTools.net, Clientcide, The MooTorial, David Walsh Blog, etc. We will also pay attention to most-searched terms and aim to ensure the search feature is providing sufficient, quality results.

This enhanced search release is considered beta. We will soon be adding further enhancements based on team goals (including full site search, etc.) and feedback provided by our most valued asset: the MooTools community.

Special thanks to Darren Waddell (fakedarren) for all of his hard work in implementing and maintaining the new search system!

MilkChart

MilkChart is an outstanding set of MooTools classes that create robust charts from your static data. Chart types include column, bar, line, scatter, and pie. MilkChart uses the HTML5 <canvas> tag and is only supported on browsers other than IE.

http://code.google.com/p/milkchart/

MooTools Tree Component

MooTools Core Developer Christoph Pojer (cpojer) released Tree Component, an advanced tree structure plugin which allows for drag and drop organization, cookie tree saving, and collapsible branches.

http://cpojer.net/blog/MooTools_Tree_Components

MTMultiSelect

Authored by Justin Donato, MTMultiSelect is a great plugin that allows you to select multiple items from a paginated list. You may also search the list of items to quickly identify the items you'd like to select.

http://www.justindonato.com/demo/mtmultiselect/

MultipleLinks

MultipleLinks is a MooTools class created by Merrick Christensen. MultipleLinks is a tooltip-like plugin that provides the user a list of possible destinations to click to. MutipleLinks is also highly skinnable.

http://thejavascriptblog.com/mootools-multiple-links-class/

Request.Twitter

MooTools Core Developer Scott Kyle (appden) created Request.Twitter, a very small MooTools class to retrieve tweets from Twitter. The class is flexible in that you may define the URL to query so you may retrieve user statuses, search terms, etc. Request.Twitter is an extension of the Request.JSONP class in MooTools More, showing the power MooTools' valuable inheritance system.

http://appden.com/javascript/get-tweets-with-mootools/

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your future plugins in upcoming posts!

MooTools Core 1.2.4 and 1.1.2

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.

MooTools More 1.2.4.1

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:

• Mask - An overlay class that allows you to put a semi-transparent layer above any element, including the window.
• Spinner - This class automates putting an AJAX indicator over any element.
• Form.Request - This class makes any form element into an AJAX form.
• HtmlTable - This suite of classes let you create HTML tables on the fly, update and alter their contents, make them zebra striped, selectable, and sortable.
• Keyboard - The Keyboard class provides the tools necessary to manage a complex user interface with different keyboard enhancements.

Depender

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

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.

Forge

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

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.

MooTools 2.0

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!

MooTools Dependencies Checker

The MooTools Dependency Checker by Arian Stolwijk parses you javascript files to determine which MooTools classes you need to make the file's javascript code work. Arian's dependency checker is a great tool for those looking to implement a MooTools plugin or use minified code.

http://www.aryweb.nl/projects/mooDeps/

MooTools InputMask

InputMask is a useful MooTools plugin by Core Developer Christoph Pojer. InputMask allows you to set a template or "mask" for which a string should be formatted like. This plugin is great for date, time, or phone number formatting.

http://cpojer.net/blog/InputMask_Class_for_MooTools

MooTools DatePicker

DatePicker is a great plugin by MonkeyPhysics. DatePicker allows you to provide your users with a calendar to choose dates from instead of making users type in the date. DatePicker is very customizable and allows for easy styling/theming.

http://www.monkeyphysics.com/mootools/script/2/datepicker

MooModernizr

MooModernizr tests the browser's CSS capabilities -- specifically CSS3 feature detection. MooModernizr extends MooTools' Browser.Features object. MooModernizr is a port of the original Modernizr.

http://www.aryweb.nl/voorbeelden/mooModernizr/

Speed Up Your Moo Part 1: Selectors

MooTools Core Developer Christoph Pojer shares methods for speeding up your applications through the use of optimized CSS selectors. Consider this article a must-read if you use Selectors frequently in your large web applications.

http://cpojer.net/blog/Speed_Up_Your_Moo_Part_1_Selectors

JSCocoaLoader

JSCocoaLoader allows you to develop Espresso.app code editor extensions using MooTools and JSCocoa. JSCocoaLoader’s utility classes are all powered by Mootools, and as a happy side effect your Javascripts can easily take advantage of Mootools many improvements over vanilla Javascript either by requiring a JSCocoaLoader utility class, or by requiring Mootools directly.

http://wiki.github.com/onecrayon/JSCocoaLoader-sugar/mootools-server

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your future plugins in upcoming posts!

The foundation of every great open source project is its community. The MooTools Team creates the base framework code but it's all of you that take the framework and build outstanding plugins. Here are some great plugins and tutorials that have been released recently.

MooEditable

MooEditable is a WYSIWYG editor created by Lim Chee Aun (cheeaun).
MooEditable features the usual bold, italic, strikethrough, and underline controls as well as the ability to add images, links, and lists.

http://cheeaun.github.com/mooeditable/

MooTools Intellisense

The problem: Visual Studio 2008 doesn't provide Intellisense for MooTools. The solution: Darren Waddell (fakedarren). Darren has created Intellisense for our favorite javascript framework. Grab this package to increase your productivity within Visual Studio!

http://code.google.com/p/mootoolsintellisense/

PageZoom

Lim Chee Aun (cheeaun) also blessed the MooTools community with PageZoom, a flexible zooming widget that allows you to zoom in on any element within the page. The plugin is especially valuable for zooming in on photos.

http://cheeaun.github.com/pagezoom/

Notification Message Dispatch for MooTools

Tobias Svensson has created NotificationCenter, a simple implementation of a notification center for MooTools which is heavily inspired by NSNotificationCenter from Apple's Cocoa framework.

http://return42.blogspot.com/2009/07/notification-message-dispatch-for.html

PyCow

As the description says: PyCow translates Python code to JavaScript code with the "MooTools way of class declaration". Examples of PyCow's mindblowing functionality can be seen at the PygoWave Server Google Code site.

http://code.google.com/p/pygowave-server/wiki/PythonToJavaScriptTranslator

Up the Moo Herd: MooTools Tips and Tricks

MooTools contributor Mark Obcena (Keeto) examines and explains the finer points of the MooTools Core. His articles are detailed, accurate, and must-reads for MooTools developers. Three posts have been published thus far:
The DOM Fetcher Functions, Natives, Generics and Extending the Language, Classes: Constructors, Singletons and Privates.

Why You Shouldn’t Return False in MooTools Event Handlers

MooTools Core Developer Sebastian Markbåge explains why returning false in event handlers can cause you problems. Check out Sebastian's tutorial to learn more about event bubbling and the proper way of handling events.

http://blog.calyptus.eu/seb/2009/07/why-you-shouldnt-return-false-in-mootools-event-handlers/

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your future plugins in upcoming posts!

Slideshow 2

MooTools FileManager

Moousture

Fancy Upload 3

MooTools.Mode For Coda

Keep Up the Good Work!

These are just a few of the great MooTools plugins floating around the MooTools community recently. Keep up the good work and we look forward to featuring your future plugins in upcoming posts!

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.

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

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

Thank You!

Last week we announced that MooTools merchandise was available for purchase. We've seen a great response to the announcement and we've received a solid amount of orders. Thank you for your continued support! Now it's time for us to show you our appreciation.

The MooTools team would like to announce Faces of Moo. Faces of Moo is where we post photos of you and fellow community members wearing your MooTools shirts, hats, and hoodies. What better way to strengthen the MooTools community than by showing its talented members wearing their Moo colors?

What do you need from me?

Please provide the following items:

• Name (if you feel comfortable sharing)
• Location (ex: "Los Angeles, CA, USA")
• Website URL (if you have one)
• Photo (we will crop/resize as needed, so please provide a large photo)

Where do I send my information?

Please send the information above to mootoolspeople@gmail.com. We'll get you up on the site as soon as we can.

Thank you!

Again -- thank you, thank you, thank you for all of your support and look forward to bigger and better things from the MooTools team!

• T-Shirts
• Hoodies
• Laptop Bags
• Hats

You can purchase these stylish items at: /merch

Feedback wanted!

Can you think of merchandise you'd like to see in the MooTools store? Be sure to let us know in the comments below!

What are you waiting for?

Grab your MooTools merchandise and represent your framework!

Note: The above link will attempt to send you to the correct store based upon your location. If the above link fails, please visit http://mad4milk.spreadshirt.com/ if you are in the US and http://mad4milk.spreadshirt.net/ if you are in Europe.

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

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.

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.

The MooTools project has been around for quite some time now. We've seen a few releases, some great, some less great (1.0). We've coded tons of plug-ins, scripts, websites, applications and desktop applications using our beloved MooTools. However, the community is really starting to get tired, tired of this project name. I mean, seriously, we're really fed up with cows. We even tried to "sell" it as My Object Oriented Tools, but we all know that's a stretch, and a pretty bad one.

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!

Resig wrote Tom an email, saying that he would be pleased if MooTools joined the other frameworks by implementing Sizzle in its codebase, replacing our own selectors engine. I don't really know how many frameworks are actually thinking of using Sizzle in place of their own selectors code, as the only source I can find for this is Ajaxian.

Their information about Dojo wasn't correct, so I'm assuming that information about other frameworks is incorrect as well. I do know that Dojo is considering including Sizzle as part of the Dojo foundation, based on an email Dylan Schiemann wrote to Aaron Newton. As I understand it, Sizzle would become a Dojo Foundation project, with the ultimate goal of including it into Dojo Toolkit. They have this idea of having the major framework developers all contribute to a unified CSS selector engine.

Now that you know the general picture, let me explain why this is a bad idea not only for MooTools, but for any framework other than Dojo and jQuery.

We're trying to assemble a comprehensive list of all our plugins. As part of this effort, we're asking all plugin creators to send an email to plugins@mootools.net with the following information:

• Plugin Name
• Plugin URL
• Plugin Description (one line)
• Plugin author name and link (if applicable)

At this time, we're only interested in collecting data on plugins which are compatible with the 1.2 release.

This is a temporary measure until we get a more interactive system in place.

Not only has the API been completely revamped, but there have been several significant changes to the site and the way the MooTools community interacts.

With the initial release of Adobe AIR, a lot of web developers (myself included) are starting to get excited about developing rich web applications that run natively on the desktop across platforms. We've already seen several great AIR apps popping up all over the Internet, and thought we'd try our hand at creating one of our own.

Snippely was created by myself, Tom Occhino, and Valerio Proietti as our first attempt at creating a robust and useful AIR application.

The first big feature we've been working on for 1.2 is Documentation.

1.2 Documentation is in fact almost 5 times more detailed than it was in version 1. Every class option has now its description, every method has a complete list of arguments along with description, type, and now every functionality comes with a code example -- sometimes more than one. If you want to see it for yourself, here is the temporary link for the 1.2 beta documentation.

A lot of the new 1.2 features have now been refined. An example that I'd like to share with you now is the Element Accessors feature. This is completely new for 1.2, aimed at making it easier working with elements and their attributes, properties or "special attributes". Continue reading for 1.2 code examples.

After months in the making, we can confidently say that MooTools 1.2 is now feature complete. However, there are still some bugs left to squash.

Head over to MooTools download page to start playing with it right away.

I spent a half hour tinkering around in Aptana, downloading MooTools 1.1, and setting up a few tests. The result is extremely pleasing. Not only is MooTools way better and easier to use than I remember, but it works out of the box with AIR.

That's Very nice to know!

I personally haven't yet tried MooTools in AIR extensively (i only did a few basic tests) but I'm definitely looking forward to creating something in the very near future. Maybe a downloader app? We'll see!

Check the Spec folder out from the repository and its self-contained testing suite will prove it. Show your boss, show your coworkers, and let them know that MooTools is professional grade.

To clear up some of these issues, I’ve written this article about how to get the friendliest response possible from the community.

UPDATE: SlickSpeed can now be downloaded from googlecode.

In this release we fixed a bunch of memory leaks issues, as well as some minor bugs around.

Other than some maintenance, we added the getText and setText Element methods, to help filling HTML Elements, Style tags and Script tags with text, and we added more details to the documentation.

This is a recommended update for all of you using MooTools 1.1.

If you want to, you can see the changelog in details.

So, go ahead and give it a try!

Here we're gonna post about the latest moo trends, the latest breaking changes, the latest plugins that see the light everyday.

Hoping its enough for an introductory post, I'll leave you at better things, for now.

Cheers

Valerio