After a bit of work, I’ve released our changes for MooTools 1.2.1. What took so long? Well, mostly it was the change to Browser, which used to be a hash but is now just an object. But in addition to this there were a few things that required a bit of effort to incorporate.

There was one breaking change: Class.Binds. This previously was a Mutator, but now it’s a Mixin class that’s meant to be implemented into your own. This change means you must explicitly declare its use in your classes as well as call its main method, bindMethods. This has to do with the way that Mutators now work in classes in 1.2.1, which changed mostly to support Safari 2 and Opera.

Note that if your class uses the Options class you don’t have to call the method. You just have to implement Class.Binds into your class and declare the binds property.

I ran all the tests in our Specs tests and our Unit Tests, but not in every single browser out there. If there are any issues, please just submit tickets for them. If you have time maybe run through the tests in your browsers and see what works and what doesn’t.

A short while back I was helping out a coworker who was working on a content management system with a very rich UI. In helping him work out some of the issues he was struggling with, I had one of those rare moments where I conceived of a better way to write my own code.

Some of his struggles were performance related – he had a LOT going on, but those were really an extension of the fact that his code was kind of all over the place. What started as an interface with some nice enhancements had grown into a behemoth of functions, namespaces, dom references and conventions that he couldn’t hope to keep straight anymore.

Part of what I suggested to him was that he start treating items on the page as widgets. Every portion of the interface could be broken up into little bits of functionality with a corresponding (MooTools) class and then larger items would be comprised of these smaller things. The larger items would have their own classes as well. These would act like controllers for the smaller ones.

Over the next few weeks he refactored his code and when I saw him it was aparent that he was much happier. Relieved even. The result is a structured family of functionalities that each correspond to little chunks of his UI. He can combine these in various ways for different use cases and work flows. He can extend the classes when he needs something that’s slightly different.

His sense of relief was so apparent that I began rethinking my own approach to my code. Read the rest of this entry »

In our last post we went through all the new goodies that can be found in our release candidate of our code for MooTools 1.2. We’ve spent a bit of time fixing the few bugs we’ve found and gotten emails about (thanks!) and also converted our copies of Autocompleter (authored by Harald Krishner) and also Slimbox, (originally authored by Christophe Beyls).

Autocompleter

For those keeping score, Autocompleter has already been refactored for MooTools 1.2 by its author (the afore mentioned Harald Krishner – aka digitarald). It’s a great class and we didn’t really have any thing to change about it, so why do we include it in our libraries? Well, partly because we want to make use of it, but also because we extend it. We add Autocompleter.JsonP which implements our JsonP request class for script injection instead of Ajax. We also extend it to inject our CSS automatically, (read more about how we manage assets and how you should use these methods yourself).

Finally, we had the time to create unit tests and documentation for the Autocompleter class, which always comes in handy.

Slimbox

Slimbox is a MooTools port of the popular Lightbox JavaScript library. The author of the port (Christophe Beyls) hasn’t updated it to 1.2, but we had it in our library already. The real change we’ve made is that it’s now a class, where as with the original (and the port that Christophe did), it’s just a namespace of methods and values. By making it a class it’s possible to have options and events, for there to be more than one instance on a page, and for you to extend it to alter the functionality.

Out of the box though, it works just like the original lightbox script.

On RC2 of Our Code Base

Stay tuned for more goodness as we continue our push for our own release of our plugin libraries. At this point the code should be stable enough for you to start to actually use if you want to. As mentioned in our last post, we have specs and unit tests that you can run through in the browsers you support to see if you find any issues. As always, let us know if you find anything that’s out of whack.

I’ve created a new development repository on Google Code. I wanted to have a separate development environment for people to work on the library without having to work off of the entire CNET Javascript framework repository. I’ll be posting CiUI-only releases there before merging them with Clientside’s repository.
You can also file CiUI specific bugs and feature requests on there. If you’re interested in joining in the development, please come discuss your ideas to our Google group.

CiUI Dev Google Code repository:
http://code.google.com/p/ciui-dev

CiUI Group
http://groups.google.com/group/ciui

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.