Plugins are a fact of life when it comes to JavaScript libraries. These user-contributed code snippets provide tremendous features & functionality and save developers time by not having to re-invent the wheel. The hard part, though, is trying to filter out which ones are actually useful and compatible with your current library. Finding the right plugin can at times be a crap shoot. The MooTools team is trying to solve this issue for their community. Yesterday, the MooTools team launched the official MooTools plugin repository called MooTools Forge which aims to simplify finding the right MooTools plugin for your project.
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.
Focus has been given to making it easy see a demo, download plugins, and understanding how plugins actually work along with integration with GitHub to allow developers to easily manage their code.
Check out the video below for an overview of the MooTools Forge:
A change in Firefox 3.6 has prompted a call to upgrade from the MooTools team. Earlier versions of the library used the document.getBoxObjectFor method for browser detection but as of Firefox 3.6, that method has been deprecated and no longer available:
The reason we stress the upgrade to MooTools 1.2.4 and MooTools 1.1.2 is the removal of the document.getBoxObjectFor method in the upcoming Mozilla Firefox 3.6 release. Within the browser detection code of MooTools 1.1 and earlier versions of 1.2, MooTools attempts to identify the Gecko engine by checking for the existence of document.getBoxObjectFor. Mozilla’s removal of this method in Firefox 3.6 effectively breaks Gecko detection in MooTools 1.1 and MooTools 1.2.3 down.
MooTools 1.1.2 and MooTools 1.2.4 now use the user agent string to detect the browser in use which helps to eliminate the issue. The team urges all MooTools developers to upgrade as soon as possible to ensure that your applications continue to function as expected. The updates are 100% compatible with their previous versions.
Aaron Newton of MooTools fame is now at Cloudera, the awesome Hadoop startup, and has posted about the rich Cloudera Desktop project he has been working on.
In the post he discusses the implementation and how it uses new features in the new MooTools 1.2.4 release such as:
MooTools Depender
MooTools ships with a dependency map that powers its download builder. The modular nature of the library yields itself to custom builds, putting together a library specific to the task at hand. This allows MooTools to power, for instance, a mobile application with only a small amount of JavaScript. For the Cloudera Desktop, we knew we were going to end up with a LOT of JavaScript, and loading it all on startup didn’t make much sense. Instead, we authored the Depender application. It’s an easy-to-deploy, real-time library builder and dependency mapper. This allows our application to load with a minimum of JavaScript. When users launch specific applications, Depender loads any dependencies for that app that aren’t loaded already, and then display the application. In addition to the server side component (available in both PHP and Python/Django), there are two client side components: a stand alone version to be released in MooTools 1.2.4 and a server side application that ships with a client that talks to the server for you, which lets you do this slickness:
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 exeute immediately, otherwise it will
//wait for the requirements to load
$('someElement').reveal();
}
});
MooTools ART
MooTools at the moment doesn’t have an official, public UI system, but that’s changing, and in no small part due to our contributions to the MooTools ART project. MooTools ART is an in-development UI library that currently outputs canvas. It’s an abstraction of the canvas API and it allows developers to make style-able UI elements like buttons, windows, and icons. At the moment it only outputs to canvas (limiting its support to browsers other than Internet Explorer), but we’re working on wrappers for VML and SVG.
In addition to these drawing tools provided by the ART API is a widget-based system that has numerous features including keyboard management, event bubbling, custom styling, and more. This widget system is the foundation for many of our UI elements, though not all of them. While the basic ART API was developed by the core MooTools Team (of which I am a part), we’ve contributed most of the widgets available in the library built with that API, including a window manager, a history interface, pop-ups for alert, confirm, and prompt, split views and more.
What are the major changes in MooTools 1.2.4?
Browser feature detection favoured over browser user agent sniffing
Added Trident 6 (IE8) detection
Request can take an instance of URI as a url
JSON.stringify and JSON.parse native methods are now accessible
DomReady always fires before load event
Fix for creating a Request in early versions of IE6
Zohaib Sibt-e-Hassan has created a Mootools based mouse gesture library Moousture that is based on simplicity:
A probe, which probes the pointing device. Currently there
is a Moousture.MouseProbe (P.S. I am planning to test it on iPhone and
build any seprate probe for that).
A monitor, which tests the stability of probed
device on given intervals and accordingly notifies Moousture events
(onStable, onUnstable, onMove).
A Moousture recorder class that records the mouse
movements and invoke the guesture object passed to it.
// Create a guesture matcher, currently there are only two gesture objects Moousture.LevenMatcher, and Moousture.ReducedLevenMatcher.
gstr = new Moousture.ReducedLevenMatcher();
// Add gesture vectors to matcher object, (see details below in Create your own gestures).
gstr.addGesture([3,2,1,0,7,6,5,4], ccwCircle);
// Guesture callback function takes one parameter error recieved from matching algorithm. Threshold that value (if required) to make your gestures more sleek.
function ccwCircle(error){
if(error>= 0.6)return;
...
}
// Create a probe object that will probe the pointing device. Currently there is a mouse probe that take the $(element) to probe for. So passing a div id will cause the probe to trigger events only when they occur on the passed DOM element.
probe = new Moousture.MouseProbe($(document));
// Create a recoder object to record the movement , maxSteps and minSteps in options object will specify the maximum and minimum number of steps to be recorded, and macher is required matcher object to trigger the appropriate gesture.
recorder = new Moousture.Recorder({maxSteps: 20, minSteps: 8, matcher: gstr});
// Create a monitor specifying the interval to poll and the amount of error allowed for gesture in pixels.
monitor = new Moousture.Monitor(30, 2);
// Finally start the monitor.
monitor.start(probe, recorder);
// You can stop the gesture triggering any time by calling .stop() of monitor object.
Normally when you see a title like jQuery vs. MooTools you get ready for the flame bait. You would expect it even more so if you found out that someone from one of the frameworks wrote the post!
Well, Aaron Newton did just that, and I think he did a very good job at trying to keep as unbiased as possible. He can never be perfect since he has a certain viewpoint, and in fact in some ways when you come from that view you can easily under-share your points.
This isn't a rushed piece. Aaron has been thinking about these things for quite some time, and has really pondered it.
We've posted before about Harald Kirschner's excellent MooTools plugin FancyUpload which provides extensive functionality for handling file uploads. His newest update, FancyUpload v3.0, is a complete rewrite and includes a wealth of new features:
The API with, separated uploader and file classes, allows an easy implementation in all kind of interfaces
Events are dispatched for every step of the uploading process, to keep the interface as responsive as possible
Progress tracks the loaded size, upload-rate, estimated time and other values for every file and for the batch as a whole
File uploads can be stopped, restarted or removed anytime
New Iframe-based class for multiple, asynchronous uploads without dependency on Flash
Compatible with Flash 9 and 10 with the browse button as a transparent overlay or as an interactive image sprite
Ability to change the upload URL and add POST/GET data on runtime, customized for every file or the whole process
Easy to localize to your favourite language with MooTools.lang, share your translations with others.
To see the uploader in action, Harald has started a showcase of demos which provide excellent examples of the plugins capabilities
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:
// Animal.prototype.options is now {says: 'meow', color: 'brown'};
This is especially useful when overriding default options in classes, such as Request.
Upgrading to this version of MooTools only requires that you drop in the new version. There aren't any changes that require changes to sites that implement these features.
MooTools More
Also with this release comes a large update to the MooTools plugin library, MooTools More. Previously this portion of the project featured about a dozen add-ons. The new release features 48 plugins, adding things like FormValidators, new effects, JSONP support, numerous enhancements to native objects like String and Element as well as robust URI and Date classes. They plan on adding new plugins regularly as this portion of the library grows over the next several months.
Clientcide
Relatedly, MooTools contributor Aaron Newton has released an updated version of the Clientcide MooTools Plugins to support these new plugins. Many of the plugins that are now officially part of the MooTools project came from Clientcide's collection of plugins. For anyone using the Clientcide plugins you can find compatibility scripts on the download page there. He notes that there are one or two breaking changes for users who were using some of the plugins that moved over to MooTools More.
Joining the world's collection of Growl-related libraries is Notimoo, a beautiful Growl implementation for MooTools. It's a little more sophisticated than most of the Growl ports as it supports persistence messages (that require a user's click to clear and scroll into view) and allows you to configure where on the screen the messages appear:
If you're a coder who likes to blog a lot, you know the value of a good code syntax highlighter. It helps to draw attention to your code snippets and sets them in a context easily identifiable to anyone who has used a code editor. José Prado came up with a MooTools-powered extension called Lighter.js that provides this capability.
Implementing the highlighting is very easy to do by creating a container element around the code to be highlighted and uniquely ID'ing it so that the container can be found via MooTools built-in DOM traversal factory method $(). You can see an example here:
// Object style syntax with files in same level as html document.
var myLighter = new Lighter('jsCode', {altLines: 'hover'});
// Element style syntax with files inside of a folder called "js".
$('phpCode').light({
altLines: 'hover',
path: 'js/'
});
// Highlight all "pre" elements in a document.
$$('pre').light({altLines: 'hover'});
Ajaxian.com uses a code highlighter as well so if you compare the code above to the screencap below, you can see the similarities. MooTools developers should find it very easy to output a concisely layed out code snippet.
There's no official demo for the extension but you can actually see it in action on Jose's project page since the code examples he references are actually highlighted by his extension.
It’s been some time since TextboxList got some attention. It is undoubtedly one of the my most popular JavaScript projects, along with the famous Fancy Menu (MorphList) and its slideshow sibling, BarackSlideshow.
TextboxList has been rewritten from scratch, and it’s more solid than ever. The first time around, elegance was not one of the goals. I focused on releasing the first open source script that reproduced the Facebook’s tokenizer.
Changes include:
* Compatible with MooTools 1.2.x
* New options, such as addOnEnter, which adds boxes upon pressing enter (useful for tags or categories widgets).
* More events, which gives the developer more power to extend it.
* Each element is now identified by an id, a plain value and a HTML value.
* Use of control, alt, meta keys no longer interfere with the elements keyboard navigation.
* Bugs with text selection fixed.
* Improved API, even more extensible.
* Plugins support
It also includes an autocomplete plug-in, which has its own feature list:
* Flexible. It does not depend on a specific data source (XHR, Json). Instead, the developer supplies the data which can come from anywhere.
* Binary search for maximum performance
* Simpler CSS with comments for non-experienced developers.
Guillermo tells us that a Dojo version is in the works, and Ajaxian reader Thomas Aylott adds "This thing is seriously awesome." Check it out!
Yvo Schaap has created a reasonably interesting real-time front-end to Reddit data over at erqqvg.com. It's actually a really cool visualization of how Reddit's stories change over time, with "yellow-fade" indications when new comments and votes and registered. Super-nice.
(The screenshot doesn't do it justice; go check it out.)
But that's only half the story. They've got a much-better-named service called "Vizeddit" that displays the same data with much richer graphics and animations:
Once again, you really need to go see it. The numbers along the bottom represent stories, and they grow and swap places over time, new ones are inserted, and so forth. You see the votes drop down in real-time, and new comments float in as well.
Guillermo Rauch, who has a really nice looking site at devthought has created APNG a class to bootstrap animating PNG images:
APNG provides simple frame-based animation functionality. It’s main goal is solve the problem of animating alpha-transparent images (PNG format).
Features
APNG is very flexible when it comes to the method of displaying the various animation frames.
The default behavior is taking the filename, for example spinner.png, and changing the src or background-image attribute to spinner-2.png, spinner-3.png and so on.
If the useNative functionality is in place, which is set to be on for Firefox 3 and Opera 9.5, the Javascript-based animation is not run. I encourage you to create an actual APNG for the default frame (spinner.png). If you do so, you’ll see increased performance for the browsers that support it -while also promoting the adoption of this new format-, and other browsers will just display the first frame and the animation will run via JavaScript.
You can also use background-position based animations to avoid making multiple requests, and avoid potential cache issues in old browsers.
The APNG class supports dynamic pausing, canceling, resetting and starting of animations. Frames can have a fixed interval or one can be assigned for each of them. Preloading is supported, which can prove useful for long animations or animations that are initialized and not run from the start.
MooTools Core developer Aaron Newton recently took on the task of coming up with a complementary library to the MooTools framework that would provide enhanced capabilities beyond what the standard JS MooTools core lib could, or should, provide. The results is a new project called MooTools More which aims to provide Moo developers with a set of official plugins which are well documented and supported by the team. Yesterday, the More team released their first beta which currently includes:
Class extensions including a Binds mutator, easier refactoring, chain pausing and more.
New Native extensions including more love for String and Array, plus a fully featured Date Native and a URI extension to make managing links downright fun.
More Element love with help for managing text selection and relative positioning (put this box’s lower right corner next to the upper right corner of that other box…)
Form love including a robust and extensible form validator and a class for displaying hint text over an input.
Extended Request functionality including JSONP support and Queuing.
Support for language localization for classes that output text (days of the month, months of the year, form validation errors, etc)
We've featured several implementations of the parallax effect here on Ajaxian. The newest creation comes from the team at Piksite who recently released their MooTools-powered mParallax extension:
mParallax is an adaptation for MooTools framework of jParallax whose its author, Stephen Band, describes it like "jParallax turns a selected element into a 'window', or viewport, and all its children into absolutely positioned layers that can be seen through the viewport. These layers move in response to the mouse, and, depending on their dimensions (and options for layer initialisation), they move by different amounts, in a parallaxy kind of way".
The image really doesn't do it justice and you should check out the demo to really get a feel for the capabilities.
As Moo team member Aaron Newton said, "For all you people using MooTools to make your own 8-bit side-scrolling NES clones, this is your library."
Aaron Newton has written two interesting pieces on MooTools.
First, he gives us history on the library as a way to explain where it is today, and why some people are concerned that the core isn't moving that fast (which others would call a feature!):
Because the current state of the library is very stable, the core developers are focused more on the things they use MooTools for, rather than improving the framework itself. Development on the framework core is driven by need mostly, and right now, MooTools 1.2 serves the needs of those of us who develop it quite well. That’s not saying that there’s no room for improvement (there are certainly bugs that can be fixed in Lighthouse, but most of these are minor). But for the most part, due to the focused nature of the MooTools core, there’s not a tremendous need to churn through the code constantly.
In other words, precisely because MooTools itself is so flexible and because the core developers are so focused on delivering only what is needed in the framework and not adding features for their own sakes (and relying on the rest of us to fill in the gaps), it means that to a large extent, the MooTools framework doesn’t need a lot of maintenance or enhancement. It does what it does, it does it well, and for the moment, it does not need more than that. Perfection is not attained by adding everything you can, but rather by removing everything you can. Or something.
The MooTools 1.3 Upgrade Path
Friday, January 23rd, 2009 @ 2:15 pm | filed under: MooTools | ShareThis
In the last week or so Valerio and others (myself included) have been working on the changes that are headed for MooTools 1.3. You can dig around in git-hub in various developer branches and see some of this stuff flying around, but frankly, it’s all in rough draft mode and is likely to change.
One of the points of discussion are all the $ methods. $type, $lambda, $try, etc. are all in the global name space and kind of just… there. They exist as stand alone methods because, by and large, they don’t really belong anywhere. In an effort to both clean this up a bit so that methods are where they “belong” as well as to clean up the global namespace a little, Valerio and others are discussing where to put these things.
