Archive for July, 2009

JavaScript Conferences This Fall: The Ajax Experience and The Rich Web Experience

July 30th, 2009 by Aaron N.

Many of you may have noticed looking at the schedule of speakers and events at the Ajax Experience (this September in Boston) that many of the speakers from previous years are not present. I will not be attending, and the same is true for the Prototype team, the Dojo team, the jQuery team, as well as speakers like PPK and others. There’s a reason for this that I won’t go into, but I think it will suffice to say that the conference is shaping up to be a little less… complete this year.

Instead I’ll be speaking at the Rich Web Experience in Orlando, FL, Dec 1-4. I’ll be giving a few talks there (3 or 4) and it’s looking to be like a much more interesting conference. If you’re into MooTools I hope to see you there and if you’re into JavaScript and rich web apps in general, then I think the conference should be worth the trip. There’s not a lot of detail on the RWE site yet, but I hope to see some stuff up soon. You can actually get past the “coming soon” page and into the bios of speakers from the last conference and get an idea of the kinds of topics covered.

If you end up going to the Ajax Experience this year, please let me know how it goes. I’m curious to see how it fairs without any representation from all the frameworks…

Using Class.Occlude to Create Singletons

July 13th, 2009 by Aaron N.

In my last article I talk about using an instance of Events to allow for loose coupling of functionality to limit dependencies as well as the use of singletons. There was a comment at the bottom of that article that I thought worth sharing and expounding upon:

I’ve been using Class.Occlude and occluding to document.body when I need a singleton. Works like a charm. – Kris Wallsmith

I thought this was a great idea and thought I’d explain what he means for those of you perhaps unfamiliar with Class.Occlude.

What Class.Occlude Does

Class.Occlude allows you to define a class that is tied to a DOM element (as most are) and to prevent that class from creating more than one instance for that DOM element. If you created a class that, say, validated a form, and you wanted to ensure that the user (the JavaScript user – not a site visitor) of your class didn’t attach two instances of that validator to the same form twice, as doing so would result in, say, a state where it was impossible to submit the form, you could use Class.Occlude to ensure that even if two instances of the form validator were created, only one would do anything. Indeed, the second time you tried to instantiate the validator class you would just be returned the first one. Here’s what it looks like:

var FancyFormValidator = new Class({
  Implements: Class.Occlude,
  property: 'FancyFormValidator',
  initialize: function(form) {
    this.element = $(form);
    if (this.occlude()) return this.occluded;
    //...the rest of  your awesome validation logic
  }
});
var fancyValidator = new FancyFormValidator($('myform'));
var fancyValidator2 = new FancyFormValidator($('myform'));
//fancyValidator === fancyValidator2

Using Class.Occlude to Create Singletons

So what Kris does (per his comment) when he wants an instance of a class but wants to ensure that there is only ever one instance, he occludes the document body. This means that even if you try and create a new instance of that class, if you’ve already created one, you’ll be returned the existing one.

For example:

var SingleFoo = new Class({
  Implements: Class.Occlude,
  property: 'SingleFoo',
  initialize: function(arg1, arg2, etc) {
    this.element = $(document.body);
    if (this.occlude()) return this.occluded;
    //the rest of your stuff goes here
 }
});
var foo1 = new SingleFoo(a1, a2, etc);
var foo2 = new SingleFoo(b1, b2, etc);
//foo1 === foo2

A clever solution, if you ask me.