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.

In two languages that I use often (PHP and Javascript), there's 2 different equality operators when comparing values. It's become quite common to see places expressly tell you that you should only ever use one of them. That the other is evil. People see this, and then point fingers whenever you use 2 equal signs instead of 3. Here's perfectly valid reasons to use equal operator (==) instead of identity(===).

I've talked previously about getting private variables and methods in your classes , but doing so was always kind of hacky.  In Javascript, elements don't have a native way to hide properties.  So we have to come up with creative ways like using closures .  In MooTools 1.2.3, we have a way to protect class methods.

MooTools lets you listen to events from 2 mediums: Elements and Classes. From classes, you can fire any event you want, and listen for it elsewhere. But with Elements, events are usually tied towards native DOM events. MooTools gives you the ability to define custom events for elements, by adding an entry to Element.Events .

With this in mind, we will consolidate the process of keeping track of one-time events in our custom event.

As I continue to flesh out my MooTools MVC framework, I found a neat way to implement a templating system, using only what MooTools gives me. The goal of templating systems is to allow you to write in your target format (usually HTML), and denote where variables should be tied in.

var example = 'My name is {name}.  I love {passion}';

...

Batch programming is certainly very easy to understand and write. You order a todo list and give it to the compiler/interpreter. It's what's usually taught first when you learn to program, and even in some server-side languages, you batch program (PHP doesn't have events at all, for instance). However, persitance applications that live on the desktop (and perhaps Ajax applications with minimal page refreshes) rely on event-driven programming. You set up a user interface, and then wait for the user to do something to that interface, and then respond to the event.

This is all well and great. But I've hit a problem a couple times recently as I create more desktop applications. I thought this would be easy to find, since I've hit the problem often and early. But I haven't, so I'll have to solve it myself. Sometimes, a component might have a one-time event that you need to listen to, and you don't know if that event has fired or not.