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.

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.

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

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 »

Given how the iPhone's growth has made some ripples in the world of mobile browsing, we here at CNET decided to spend a little time and make an iPhone friendly version of our sites. At first I (Vladimir Olexa) considered the excellent iUI from Joe Hewitt but eventually decided to write our own.

The result is CiUI (CNET iPhone UI) that mimics iPhone UI behavior. It's already being used on CNET's iPhone page (http://iphone.cnet.com). It's been greatly inspired by iUI with a few key differences:

1. AJAX calls are performed after a page slides
2. DOM doesn't get overloaded with "pages" as they load. Instead, two DIVs are constantly being reused
3. Page titles are set on the source page, not on the destination page
4. Only specified "a" tags are assumed a part of the UI

| 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.

via Ajaxian:

Jan Odvárko "missed two movie nights" to create cookie support in Firebug. His Firebug plugin, Firecookie, gives you access to view, search, create, remove, and manage the permissions of a cookie, all from within a Firebug tab.

Firecookie creates a log entry every time when a cookie is created, changed, deleted or rejected (an option you can change).

Jan is looking for comments.

He has also written a nice tutorial on extending Firebug. It is great to see sub-plugins for Firebug such as YSlow, Firecookie, etc. Do you know of any other good ones?

NOTE: There are, of course, separate Firefox plugins for cookie management.

Hi Gang,

I've been picking up more and more chatter regarding the imminent release of Mootools 1.2b and I keep getting emails and whatnot asking about CNET's codebase, which works in 1.11, but not so well in 1.2 (even with the Mootools compatibility layer).

We're working on it and we've made a lot of progress. We've now migrated ALL of our code and have only the 3rd party scripts we support (Slimbox and Autocompleter) left to port. But even then we're not ready to release it - or even post a release candidate - until we've done some QA.

So this post is just to tell you all that, yes, we're porting it all to 1.2 and that it's not that far off. You can, if you like, browse the documentation for the new scripts here:

http://clientside.cnet.com/docs/Core

We've rearranged things a bit (more on that in a later post), renaming some classes and methods and whatnot. We'll also have a compatibility layer that should make our code work with Mootools 1.11, as well.

Other plans include a download page much like the Mootools download page (finally!), specs (unit tests), and demos.

Stay tuned; we'll have a release candidate for you to start playing with in another week or so.

-aaron

Ajaxian has a post up about an article from the former VP of Palm regarding the death of Mobile Application development at the hands of the web. I've been chewing on a mobile web app in my head the last few weeks for my startup (I still spend time at CNET, I also recently launched my own project) and reading this was interesting. Here's a short clip from the Ajaxian post, which itself is an excerpt from the full article.

Michael Mace, a former Palm VP, says the business of native mobile apps is dying. He includes a quote from Palm veteran Elia Freedman summarizing why some of us have found mobile application development to be a deeply frustrating experience.

From the technical perspective, there are a couple of big issues. One is the proliferation of operating systems. Back in the late 1990s there were two platforms we had to worry about, Pocket PC and Palm OS. Symbian was there too, but it was in Europe and few people here were paying attention. Now there are at least ten platforms. Microsoft alone has several — two versions of Windows Mobile, Tablet PC, and so on. [Elia didn’t mention it, but the fragmentation of Java makes this situation even worse.]

I call it three million platforms with a hundred users each (link).

I was helping someone today with their javascript and they asked me about how and when I manage errors in the classes and functions that I write. I wrote him back an email which I think actually could be useful to others, so here it is.

There are three types of error handling that I use:

• Graceful: if possible, just ignore the error and continue with some default state or without a meaningful value
• Debug: throw a warning to the dbug.log method but continue otherwise
• Break: Either explicitly throw an error or (more often) just let the error that is thrown at runtime be thrown

| Read the rest »