McArthur GFX

There's a couple ways you can define globally accessible variables in Javascript. And it turns out that in JScript, they actually mean different things (as opposed to all other implementations, where they're the same). This meant my GetClass implementation just plain wouldn't work for Internet Explorer. Well, that's no good, since that's a basic building block of my MooTools MVC framework. Now, I could require all classes be created explicitly, like window.Task, but that makes for a very inflexible pattern. And there's no reasonable way to explain to users why I'm requiring that.

So instead, I delved into JScript to find a way to let me iterate all global variables.

I've updated MGFX.Tabs to have a random slide function. It just uses Math.random, and a slight modifier to insure the random number isn't already the current index. Since I believe in semantic versioning, and this is a feature update (not a bug fix), but not breaking, its should be a new minor version.

var tabs = new MGFX.Tabs($$('.tabs li a'), $$('.tabs .content'));
tabs.random();

We've already learned that to make our Javascript load faster, we should be listening for a domready event instead othe window onload event. However, sometimes, you can actually make too much Javascript reliant on that sacred event. And when you do that, you can get quite the jump or flicker in older browsers.

We use a proprietary text replacement program instead of sIFR or Cufon or anything else out there. We call it Typostream. On one of my recent projects, we had several features of the web-site requiring extra Javascript functionality, along with a good portion of text being replaced. Originally, I had all of this Javascript being executed on DOM ready event, as best practices recommend. However, viewing the site in Internet Explorer revealed some amazingly laggy results.

LOG: Total: 244, Since Last: 244
LOG: Total: 1992, Since Last: 1748

As I continue to work on my MVC implementation in MooTools, I continue to find new hidden features in MooTools. This weekend, I was adding a view method to the controller, as a shortcut to creating a new View and rendering it. One of the arguments is the view file name, but I also wanted some automagic like CakePHP. It'd be great if the view function could determine the file name based on the function that called it.

Here's what I mean:

var ItemsController = new Class({
	view: function(view_name) {
		if(!view_name) {
			//viewname should default to 'controller/method'
		}
	},
	list: function() {
		$(this).grab(this.view()); // 'items/list'
	}
});

Last week saw the release of the MooTools Forge. And that's fantastic news for the MooTools community. If there was ever one thing MooTools lacked compared to jQuery, it was an easy way to find other MooTools code.

I love closures. They are an excellent tool any Javascript programmer should have in his tool set. They let you do fantastic things, and are the way things like the Module Pattern are possible. But they can also be tricky. I'll show you a couple ways they've managed to fool me, so that you can be aware of them when you use them in your programs.

Quite a while ago, I released a simple-to-use MooTools tabs class, and it continues to be one of the most frequented posts on the site. With so many people obviously desiring a MooTools tabs plugin, I've added a few new features to the plugin, as well as moved it to Github for inclusion in the future MooTools Forge.

I just wanted to document this rather frustrating bug here, so I can look it up later, and hopefully help anyone else who is running into something similar. This bug involves select tags, specifically setting their innerHTML property.

I had a list of options to give to the user, and a select box would work perfectly. Since DOM methods have burned me in the past, I felt innerHTML was the safer route. It appears, that they both have safety curves like a sine and cosine graph.

One of my favorite methods that I use constantly in various interfaces combines fading and removing of an element. It could be a table row, or list item, or a div, but often times when I wanted to remove something, I'd like it to remove with a fade. And not always wanting to write to listen for the complete event and then remove the element. So I'll show the original I use in Prototype, and then a port to MooTools.

Dates are a peculiar type of data that we have to work with. In some sense, they aren't a number, but instead are a combination of month, day, and year. But at the same time, in most programming languages, they are fundamentally a number: the number of seconds since the Unix epoch.

In our heads, it's quite easy to do Date math. Moving forward a week requires just adding 7 days. How would you do that with a Javascript Date? Programming languages usually try to make working with Dates as logical as it is to do in our heads. So I a little surprised at an irregularity in using Dates in my math.