3rd Party Libraries: Posts

After a lot of start and stop work I’m happy to announce that CNET’s javascript libraries are now nearing final release for MooTools 1.2 compatibility. We announced our RC1 release of the libraries. We’ve spent the time since then writing lots and lots of tests to validate the codebase. At this point we’ve spent all our time writing the tests, but we haven’t actually put everything through QA yet. Still, we’re much more confident in the current state of the code and have started using the code in our live environments in a limited fashion.

Unit Tests and Specs Tests

MooTools itself comes with a specs runner from JSSpec. We’ve made use of this to write specs tests for the portion of our libraries that can be tested this way. You can see and run these tests here: http://clientside.cnet.com/cnet.gf/svn/Specs.

Because a lot of our work is more interactive, these specs tests won’t work to verify that our code works well, so we’ve written a unit tester suite. You can run through all the unit tests, which require you to start a test, perform some action, and then verify that it worked correctly (for instance, if you were testing our DatePicker class, you’d start a test, then click on an icon and choose a date and verify that the resulting date was the one you selected). You can view the unit tests here: href=”http://clientside.cnet.com/tests/

What’s New?

Here’s what’s new in our 1.2 conversion:

• New docs: http://clientside.cnet.com/docs
• New download page: http://clientside.cnet.com/js
• Everything has been refactored, in some cases just minor tweaks to work with 1.2, while in other cases things were completely rewritten. The interface to most of our classes and methods has been unchanged.
• New file organization mirrors MooTools. This means you can get a compatibility layer for 1.11 code.
• Some things have been renamed and cleaned up. Most notably Fx.SmoothShow is now Fx.Reveal, Fx.SmoothMove is now just Fx.Move, and stickyWinDefaultHTML is now StickyWin.ui.

How You Can Help

Our codebase is ready for consumption but it’s possible you’ll find errors. Run through the specs tests and unit tests in the browsers you use and let us know if any fail.

We haven’t tested our compatibility layers very thoroughly yet. If you have some pages that use our libraries already, see what happens when you include MooTools 1.2 and our current code with the compatibility layers enabled for both.

If you find any bugs, you can post comments here or contact us directly.

So I was asked yesterday the following:

Why does Browser use merge but Element use implement?

And after composing a lengthy reply, I thought it might be useful to post it for others: | Read the rest »

After many hours of toil we're ready to release our first candidate of our public libraries. We've put a lot of work into keeping up with Mootools 1.2 and all its goodness, so hopefully the wait has been worth it.

First up, changes!

We've refactored nearly the entire library and in most cases the changes don't affect the actual interface to the classes and methods, but not always. Like Mootools, you can download a compatibility layer which will preserve the old syntax if you have code that you haven't updated yet.

The most interesting changes are as follows:

• Fx.SmoothShow/SmoothHide is now Fx.Reveal, Element.reveal(), and Element.dissolve()
• Fx.SmoothMove is now just Fx.Move and Element.move()
• stickyWinHtml() is now StickyWin.ui()

There are other changes, but these 3 are the big name changes. You can browse the Compatibility files and see the actual changes if you want to compare, but other than that all the new details are in the docs. Speaking of which...

New Docs

Check it out, yo: http://clientside.cnet.com/docs

These new docs are obviously rendered using the same docs as the new Mootools engine. The docs would be in much worse shape if it weren't for one David Kelly who found the svn branch we've been working in a few weeks ago and started spellchecking everything for us. David found most of the odd formating errors and various syntax snafoos, but you might still find some. Let us know if you do.

Fancy New Download Page (Courtesy of Mootools.net)

It's an obvious rip off of the Mootools download page, but we're still really happy to have it. You can now click and download any portion of the cnet libraries and get it as a single file. You can include Mootools 1.2 with your download here or not, up to you.

Served fresh daily: http://clientside.cnet.com/js

No 3rd Party Scripts Love (yet)

We have two 3rd party scripts we include in our libraries: the awesome Slimbox and Digitarald's Autocompleter. We haven't ported either of these yet but we'll get to them soon enough. Autocompleter has already been refactored for 1.2, so it's just a matter of us extending it to support our specific classes (the "multi" variants and the jsonp version).

Coming soon

• Updated Mootorial (for both Mootools 1.2 and our code)
• Unit Tests
• Bug fixes, to be sure

So get started, and let us know how it goes!

P.S. A big thanks goes to Valerio and the rest of the Mootools team. Aside from Mootools itself, the download page and documentation engine are nice additions to our offering and we appreciate them letting us rip them off.

Ajaxian's annual framework survey is out. Being a Mootools developer, of course my primary interest is in seeing how it stands up.

Looking at the chart on the right here, you can see that it's #5 on the list, although I'd argue that Scriptaculous isn't a framework so much as an add-on to Prototype. If you're using Prototype, you're likely to use Scriptaculous as your effects interface.

So by that logic, Mootools is doing quite well and growing since last year (it was a write-in candidate not listed as a choice in the survey in 2006, yet still garnered 11% of the vote).

There's more to this survey if you're interested. Head over to the Ajaxian post on the topic.

I started working on the update for the Mootorial for Mootools 1.2 today and one of the new pages I've added attempts to answer the question: why should I choose Mootools over some other framework?

The page itself is a wiki, so for anyone reading this that represents one of these other frameworks, I invite you to tweak it if I am representing these others poorly. I hope I'm not.

So. Why should you choose Mootools vs. some other framework?

Ajaxian today posted about Greg Houston's MooTools-based MochaUI class that draws draggable, resizable, rounded-corner and dropshadowed boxes without using images. It uses canvas tags and Google's ExplorerCanvas. Looks like Greg didn't take advantage yet of Olmo Maldonado's MooCanvas, but maybe he'll upgrade. His demo works well across browsers and platforms (with a small bug in FFox/Mac that custom scrollbars can fix).

It might be a while before you see these on CNET, but I'm starting to finally see a happy place between our design and production teams where design gets their rounded corners and dropshadows, and production doesn't have to deal with the headaches that come with them. I also expect that we'll see a bunch more development around ExplorerCanvas (and MooCanvas) in the near future.

Greg's code seems to be pretty well-rounded, but he hopes to add some new features (including modal windows and the aforementioned custom scrollbars). He says this is "an on going [sic] exercise to help me become more familiar with both MooTools and the canvas tag." Keep up the good work, Greg.

I might add that Aaron lamented via IM, "stickyWin's days are numbered." It's been a good run, stickyWin, but I don't think we're done with you quite yet.

Valerio posted over on the Mootools blog today about the release of Mootools 1.2 beta. I argued with him that this should be Mootools 2.0 because, once again, nearly every single method and class has been tweaked or rewritten wholesale.

Mootools 1.11 was released just over five months ago and since then the development team has been hard at work (I've been slacking, mostly reading code commits and giving feedback; you won't see my name in the commit log very much on this release) and the product is something I've been eagerly awaiting. The list of what's new is daunting and will take you a few minutes to read and many more to grok.

I especially look forward to Fx.Tween and Fx.Morph, the awesome test suite integration, the new and improved Hash, and the new Sortables (which I've already been using in a version I ported back to 1.11 for myself). But that's not all! Call now and you get like a bazillion other new methods and shortcuts and browser fixes (oh, I forgot the new Iframe class).

SRSLY, this release is awesome. Congrats all around to the Mootools dev team, myself excluded.

A note on our stuff: The Mootorial will be a few weeks in the updating but it'll catch up eventually. Our code base is a different story. It's going to take a while to migrate all our stuff to 1.2 as we haven't started yet (I learned my lesson previously; don't start migrating for a Mootools release until the release is done or else you're chasing a moving target, and Valerio and team are far more productive than I am). It should continue to work with the compatibility script for 1.2 installed, but we haven't tested for that. Stay tuned as we start on this process.

The first beta for MooTools 1.2 is finally here!

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.

read about all the new stuff in this release >

Over on the Mootools forums we have an announcement up regarding the release of Mootools 1.2rc1. :

To those who have been watching the SVN lately, you've probably been noticing some big changes to the structure of MooTools. We just got finished with a big merge into trunk that combined many things.

Mainly, these things are:

- Completely rewritten documentation, in a brand new format, for a brand new parser (ibolmo wrote about 7,000 lines of documentation, lets all give him a big thank you...)

- a new trunk structure containing Three directories (Source, Compatibility, and Test)

- Backend code restructuring throughout the entire framework.

- An enhanced download page that allows you to include compatibility scripts that will make (almost) all old MooTools code work. (also check out the new YUI compressor...)

Now what we need from all of you:

- over the next week or so, wed like to get as many people testing out MooTools 1.2dev as possible.

- please submit bug reports as they come up both in here and via trac tickets.

- make your reports as detailed as possible and include sample code and demo links if possible.

Things you should be aware of:

- There are a few breaking changes in the trunk, but almost everything is taken care of by the inclusion of the compatibility scripts (right in the downloader).

The first issue deals with the extending of Classes and Natives via Class.extend. Instead of:

Array.extend({ ... });

You must now use:

Array.implement({ ... });

These changes have been made to keep the api clean and consistent, and the changes are certainly for the better. We may provide compatibility for the above issues (Class.extend compat. added), but moving forward, you should write your new code like this. Everything else should still work, but if you have any questions or problems with your scripts, please let us know so we can get everything in order for a release soon ;) I will update this post as any developments are made.

Download the latest trunk now! and start using the new and improved moo!

Thanks all for your time, and your help. -Tom

There's a nice new article by Jonathan Snook on Adobe AIR that is worth the read. I was about to write all about it here but I see that Ajaxian wrote about it yesterday. I'll, instead, just post what they had to say about it:

It looks like everyone wants to put out some form of Adobe AIR application and Twitter-based apps seem to be all of the rage, possibly because of the ease of integrating with Twitter's API.

Apparently, Jonathan Snook didn't want to be left out of the fun and created his new Twitter app appropriately called Snitter:

I built Snitter for a couple reasons. First off, I wanted to take AIR out for a spin and see what it could do. Secondly, I find using the Twitter web site frustrating at times because it doesn't offer up features that I've always felt could be easily added. So, I've gone ahead and built an app with the features that I've always wanted.

Jonathan definitely has a flare for style and he's brought that over to a really nice looking application:

You'll need the following to run the app:

• A Twitter account (duh!)
• The Adobe AIR runtime
• The Snitter AIR file

Mootools contributor Digitarald (i.e. Harald Krischner) posted a while back about Mootools selector goodness that's been added. CSS3 selectors arrive and it's all nice stuff.

The $$() function in MooTools uses CSS selectors to select Elements from the DOM. Since last week, basic CSS2 was supported, but now the developers added more selector features. Check out the slick speed test and the blog entry about the tale of pseudoselectors describing the details and the development. I’ll describe some basic about the selectors here …

That was already possible

PLAIN TEXT

JavaScript:

// Select all anchors
$$('a');

// Select all anchors inside list items
$$('li a');

// Select all anchors with class "ajaxified" inside an element with "menu" id
$$('#menu a.ajaxified');

// Select all anchors and images with the "title" attribute
$$('a[title], img[title]');

// Select all anchors with the "href" attribute, beginning with "http://" and with "ajaxified" class
$$('a.ajaxified[href^="http://"]');

$$ returns an Array of Elements, extended with Elements methods, so you can do this:

PLAIN TEXT

JavaScript:

// Adding an ajax request to all ajaxified menu anchors
var menuAjax = new Ajax('', { // url is empty, we set it dynamically
    autoCancel: true, // when a new request starts and the previous one is running, its cancelled
    update: $('content'), // the target
    evalScripts: true // maybe we have script tags in the content
})

$$('#menu a.ajaxified').addEvent('click', function(e) {
    menuAjax.url = this.getProperty('href');
    menuAjax.request();
    return false; // see NOTE
})

This simple example adds ajax loading to menu items using the href url. Now you can add e.g. effects when the content is injected, a spinner when the request starts, selected items and more fancy stuff.

NOTE: This event handling is new in the svn trunk. You no longer need to use new Event(e), bindWithEvent or bindAsEventListener when you use Element::addEvent. The given event is automatically the extended cross-browser Event class and of course this (the scope in your event callback) is the Element. Furthermore you can return false to stop the event propagation.
When you want to use this example with MooTools 1.11, simply stop the event with new Event(e).stop().

And what is new?

The new CSS3 selectors are not ALL available like shown in w3c-specs, we added the useful ones. Of course the whole thing is super fast, uses XPath internally for cool browsers and is, like most things in MooTools, extendable.

PLAIN TEXT

JavaScript:

// All list items which are childnodes of ul#top
$$('ul#top> li');

// all list items following li.head with the same parent node
$$('li.head ~ li');

// all anchors containing the word "Hello"
$$('a:contains("Hello")');

// The selector implementation and parsing allows also short-hand notations ...

// first list item in an ul element
$$('ul li:first');
// same as
$$('ul li:nth-child(1)');
// same as
$$('ul li:first-child');

// every second li inside an ul, starting from the second
$$('ul li:nth-child(2n)');
// same as
$$('ul li:nth-child(even)');
// same as
$$('ul li:even');

// simple and fast zebra table in one line
$$('table> tr:odd').addClass('odd');

Read more on The MooTools Blog – Selectors on Fire