30 June 2008

Not lovely...

Well, its not often that I have had a bad word to say about Mozilla Firefox. However, for the second time in a week, I now do.

I have been aware of issues with the Mozilla implementation of eval for some time, but the latest exposure was news to me and seemingly many others.

Full details can be found here. There is no reliable way round that I can find as yet so I will continue along the assumption that in the JavaScript world, nothing is safe.

I will still use a module pattern (as I have discussed before in a previous post) and I will still call "private" members private. I will also continue to discourage the use of evil eval.

Douglas Crockford has a few things to say about Firefox in general and had his own comments about this latest issue.

I am deeply disappointed frankly. Firefox 3 ruined my week last week (well, truthfully, Firebug was as much to blame) and now this. I suppose its nice to see that other browser vendors make mistakes!

29 June 2008

Lovely...

This is a lovely little tool.

There is nothing else one can really say about it!

24 June 2008

Firefox 3

Well, it has been a good few days now that I have been running the release version of Firefox 3 and I thought I would share some of my experiences - both positive and negative.

First off, I like the interface updates, the "awesome bar" and the speed improvements. I have been very impressed with its stability as well.

However, I have found difficulty using a number of plugins and in particular Firebug. This is simply unacceptable. I have tried using a number of different versions of Firebug but to no avail - all were slow and often crashed Firefox.

Whilst this has proven to be just about acceptable for working at home on things such as JSquared, at work it has proven utterly useless and I have downgraded to Firefox 2 and Firebug 1.05. The improvement in performance of Firebug was immense.

How are you finding Firefox 3 and Firebug? Have you found a combination that works for you?

9 June 2008

My JavaScript patterns

Since posting about my JavaScript "rules", I have had a number of requests to expand on the patterns I use for developing my JavaScript objects.

I use two main patterns, a singleton pattern and a constructor pattern. A singleton is an object which will have only one instance within an application. A constructor is a function which when invoked with the new keyword will create an object based on its definition. These objects are known as instances.

Constructor Pattern
A constructor pattern is something which JavaScript has native support for. Douglas Crockford has previously talked about this pattern at length.

function EventHandler() {

    //constructor

 

    //private members

    var registeredEvents = [];

 

    //public methods

    this.registerHandler = function(func) {

        if (typeof func === "function") {

            registeredEvents.push(func);

        }

    }

    this.fire = function() {

        for (var i = registeredEvents.length-1; i >= 0; i--) {

            registeredEvents[i]();

        }

    }

}



A constructor is simply a function which defines various members and contains its own variables and indeed other functions. You can also define constructor logic with a series of statements which do not declare methods or private variables or functions.

Its a fairly simple pattern and it is just as easy to use. To declare a new instance of this constructor, the code is simply this:

var myEventHandler = new eventHandler();



Singleton Pattern
My aim with a singleton is to have a highly readable object formation pattern which allows for private members and the exposure of a public interface. The syntax also must ensure that only one instance of the singleton can exist though of course there is nothing to stop the object being inherited from.

I also wanted the pattern to look similar to the constructor pattern above. This should make it easier to code and maintain.

For this example, I am using a simplified version of an object in JSquared. JSquared makes extensive use of this pattern as much of the library is built up from singleton objects. The object I am using here is the cookies object. For details on how to use this within an application of your own, look out for a post on the JSquared blog.

var cookies = new (function() {

    //private members

    var cookies = {};

 

    //constructor

    //get the current set of cookies

    var currentCookies = document.cookie.split(";");

    var cookie;

    //loop through current cookies and add their values to the cookies collection

    for (var i = currentCookies.length - 1; i >= 0; i--) {

        cookie = currentCookies[i].split("=");

        if (cookie.length >= 2) {

            cookies[cookie[0]] = cookie[1];

        }

    }

 

    //public methods

    this.set = function(name, value, expiration) {

        document.cookie = name + "=" + value + ";expires=" + expiration + ";path=/";

        cookies[name] = value;

    }

    this.get = function(name) {

        return cookies[name];

    }

    this.delete = function(name) {

        this.set(name, "", -1);

        delete cookies[name];

    }

});



You will I am sure notice how similar this singleton pattern is to the constructor pattern above. The major difference is that the singleton pattern created the constructor as an anonymous function and then invoked an instance of that anonymous function immediately.

Just like when creating a new instance of a constructor, an object defined as per the constructor function will automatically be returned from the invocation. So in the example above, the variable cookies will contain the singleton.

The syntax may look odd, but it has proven itself very resilient and extremely effective. It allows for private members and functions, the public methods have access to those private members. It contains constructor logic and of course parameters can be passed in to the constructor just like they could be in the constructor pattern shown above.

As I seem to often say, its as simple as that!