Scato Eggen, in honor of Towel Day in the Netherlands, has released an open source framework called towel.js.
towel.js is an extension for Mootools, designed to make event-based code easier to write and even more important: easier to read.
At the hart of towel.js is a modular helper system called towel, including two helpers called UI and FX. These helpers produce objects that can be linked together: one object detects whether the mouse button is pressed, the other one changes style attributes. By linking these objects together a whole range of effects can be created and added to a page.
To create a simple momentum effect you only have to wire up code such as this:
The first beta of MooTools 1.3 has become available. The biggest feature is their new CSS selector engine. They aren't using Sizzle like some of the other boys, but instead have become 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 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.
new Element("input#someID.someClass1.someClass2[disabled=true]");
There are other features too:
Globals
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.
From types with love
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.
Generating your own MooTools, from your own computer
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.
Jacky Nguyen was behind a new website ExpatLiving from Singapore, and as he built out a nice view for iPhone and mobile Webkit folks, he implemented MooTouch. It is still in an early stage, and is asking for input:
MooTouch is a cutting-edge JavaScript framework built on top of MooTools that truly brings the experiences of iPhone / iPod Touch native applications to web applications. It is extremely lightweight and highly extensible, designed as a collection of loosely-coupled MooTools classes to handle all users' touch interactions. Key features include:
MooTouch.App
Full Ajax experience, dynamic content loading on demand, ZERO page refresh or re-direction
Location hash handling
History management, makes full use of the browser's back and forward buttons
Pages transition using Mobile Safari's native CSS3 GPU acceleration
Automatic hiding of the browser's location bar
Global event delegation to boost performance, and much more...
Some key behaviors that make the core of MooTouch:
MooTouch.Clickable: No more infamous 300ms delay before the "onClick" event is actually fired!
MooTouch.Scrollable: CSS position:fixed not possible on the iPhone? It was yesterday! Have full control over which content area you want to provide the simulated scrolling feature, with scroll indicators, deceleration & snapping back to boundaries features.
MooTouch.Swipeable: Bring "onSwipe" event to any DOM element you like, that's how the photo gallery was done
and more to come...
MooTouch is different from most existing similar libraries thanks to the use-at-will architecture of MooTools. You can simply just pick the pieces you need and combine them the way you like. Also, you can use any existing interface framework like iUI, iWebKit, UiUIKit, etc. for styling and put MooTouch on top to control all users' interactions with any DOM element.
MooTouch is currently still in alpha testing. It will be released under the Open Source MIT License as something I can give back to the great open-web community! All feedbacks are very much welcome.
Bastian Allgeier has developed a beautiful, native looking web application called ZooTool.
Zootool is a visual bookmark tool for images, videos, documents and links. It is completely based on Mootools, even though it looks more like a Cappuccino app!
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:
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 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.
monitor.stop();
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:
// Now I create the manager so it will display notifications from the left bottom corner var notimooManager = new Notimoo({
locationVType: 'bottom',
locationHType: 'left' });
// Showing a notification that does not disappear.
notimooManager.show({
title: 'Testing notification',
message: 'This notification will not disapper on its own. You must click on it to close.',
sticky: true });
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.
