It provides two methods that you can use in your code, isVisited and isAnyVisited.

One important note about your URL specification is that you must specify an *exact* URL that the user has been to. So, for example, if someone has visited several twitter profiles, but never actually went to the homepage or signin screen, then it would be difficult/impossible to tell whether or not they were a twitter user without a massive brute-force query.

You can download sniff.js, or view a demo.

Sample usage:

dojo.require("mdg.sniff");
var usedYahoo = mdg.sniff.isVisited("http://www.yahoo.com");
var usedGoogleMaps = mdg.sniff.isAnyVisited([
      "http://maps.google.com",
      "http://maps.google.com/maps"]);
var usedFacebook = mdg.sniff.isAnyVisited([
      "http://www.facebook.com",
      "http://www.facebook.com/index.php",
      "https://login.facebook.com/login.php"]);

Source code:

dojo.provide("mdg.sniff");
 
//
// Browser history sniffing, based on infamous blog post:
// <http://www.niallkennedy.com/blog/2008/02/browser-history-sniff.html>
//
// Sample usage:
//
//    dojo.require("mdg.sniff");
//    var usedYahoo = mdg.sniff.isVisited("http://www.yahoo.com");
//    var usedGoogleMaps = mdg.sniff.isAnyVisited([
//          "http://maps.google.com",
//          "http://maps.google.com/maps"]);
//    var usedFacebook = mdg.sniff.isAnyVisited([
//          "http://www.facebook.com",
//          "http://www.facebook.com/index.php",
//          "https://login.facebook.com/login.php"]);
//
// Works with Dojo 1.3 and 1.4 (*may* work with 1.2 as well)
//
 
dojo.require("dojox.html.styles");
 
(function(){
 
    var _this = this;
 
    this.sniffCache = {};
 
    dojox.html.insertCssRule(".dojohistorysniff a", "color:#000000;");
    dojox.html.insertCssRule(".dojohistorysniff a:visited", "color:#ff0000 !important;");
 
    this.isAnyVisited = function(/*Array*/urls) {
        for (i=0; i<urls.length; i++) {
            if (_this.isVisited(urls[i])) {
                return true;
            }
        }
        return false;
    };
 
    this.isVisited = function(/*String*/url) {
        if (typeof(_this.sniffCache[url]) != 'undefined') {
            return _this.sniffCache[url];
        }
        var link = _this.addLink(url);
        var color = new dojo.Color(dojo.style(link, "color"));
        if (color.r == 255) {
            _this.sniffCache[url] = true;
            return true;
        }
        _this.sniffCache[url] = false;
        return false;
    };
 
    this.insertSniffDiv = function() {
        return dojo.create("div", {className: "dojohistorysniff"}, dojo.body());
    };
 
    this.getSniffDiv = function() {
        var divs = dojo.query("div.dojohistorysniff");
        if (divs.length > 0) {
            return divs[0];
        }
        return _this.insertSniffDiv();
    };
 
    this.addLink = function(/*String*/url) {
        var div = _this.getSniffDiv();
        return dojo.create("a", {href: url}, div);
    };
 
    /**
     * mdg.sniff.isVisited
     * Check whether or not a URL has been visited
     * @param url String
     * @return boolean
     */
    mdg.sniff.isVisited = this.isVisited;
 
    /**
     * mdg.sniff.isAnyVisited
     * Check whether or not *any* of the URLs specified have been visited
     * @param urls Array of Strings
     * @return boolean
     */
    mdg.sniff.isAnyVisited = this.isAnyVisited;
 
})();

Lo and behold, there’s a way out! There’s very few valid excuses for not writing cleaner, prettier, more maintainable Javascript. Many of the same principles preached in Python hold true.

There are some prevalent concepts that can help us write better code. Understanding and applying unobtrusive Javascript can help alleviate everything from cluttered namespaces to browser differences and performance issues — I suggest reading the 7 rules. Following directly from that, progressive enhancement principles are fantastic to allow for graceful degradation and accessibility. Do with Javascript what we know we should do with CSS. Here’s some food for thought about progressive enhancement. Additionally, writing loosely coupled code (i.e. methods not tied directly to the DOM unless necessary) provides a separation of concerns that helps with debugging and testability. Finally, automating the testing of your code to ensure it’s doing what you think it should do (prior to sending it to QA for them to check) is powerful in and of itself.

If you’ve been bitten by the testing bug and find yourself wanting to test your Javascript code, you’ve come to the right place. The first question you should ask yourself is, “what should I be testing?”. I will focus on unit testing in this article. You should also be aware that there are powerful tools (e.g. Selenium) for integration and browser testing. But first things first.

So, what are common things done in Javascript that might need to be unit-tested? Here are a few examples:

• Client-side validation. Let’s ensure all bases are covered with validators that are written to check email addresses, birthdays, maximum lengths, etc.
• Methods that compute window sizes or element positions. There’s often lots of math, and edge cases can be killer.
• Basic things ingrained in the Dojo framework, such as class inheritance. You’ll want to ensure that your class behaves as you expect.

Let’s take the example of a email address validator and see how we might write it and test it. Here’s one method, which happens to validate a string expected to be a valid email address, with a length less than the specified maximum. This would be located at $JS/dojo1.2/src/app/validators.js.

dojo.provide('app.validators');
app.validators.isValidEmail = function(email, maxLength) {
    if (email.length > maxLength) return false;
    var pattern = /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-zA-Z0-9]{2,4})+$/;
    return pattern.test(email);
}

There are several things we might want to test. For example, we should test that the maximum length functionality works. Additionally, we should test that it doesn’t allow emails without a domain to pass through. And we don’t want to leave out testing that a valid email can pass through. In an ideal world, we would test every reasonable branch through the function, and through the regular expression itself.

Here are 3 test cases, presented in a format acceptable for the D.O.H. framework

Case 1: Too long of an email is invalid

runTest: function(){
    doh.assertFalse(app.validators.isValidEmail('123456', 5));
}

Case 2: Email without a domain is invalid

runTest: function(){
    doh.assertFalse(app.validators.isValidEmail('foo@.', 50));
}

Case 3: A valid email should validate as such

runTest: function(){
    doh.assertTrue(app.validators.isValidEmail('foo@bar.baz', 50));
}

We can then insert these into a D.O.H.-compatible test package. Open an editor to $JS/dojo1.2/src/app/tests/test_validation.js, and register the tests from above as shown below.

dojo.require('app.validators');
 
doh.register("app.tests.test_validation", [
    {
        name: 'test_validate_email_too_long',
        runTest: function(){
            doh.assertFalse(app.validators.isValidEmail('123456', 5));
        }
    },
    {
        name: 'test_validate_email_nodomain',
        runTest: function(){
            doh.assertFalse(app.validators.isValidEmail('foo@.', 50));
        }
    },
    {
        name: 'test_validate_email_ok',
        runTest: function(){
            doh.assertTrue(app.validators.isValidEmail('foo@bar.baz', 50));
        }
    },
]);

The last steps are to plug it into a test “module” (so it can be discovered by the D.O.H. runner), and run it to ensure things are working as desired. Point an editor to $JS/dojo1.2/src/app/tests/module.js, and add the following line:

dojo.require("app.tests.test_validation");

D.O.H. provides a browser-based test runner for executing tests. Assuming you have Dojo 1.2 available on your server, modify the following path to suite your installation: http://servername/js/dojo1.2/src/util/doh/runner.html?testModule=app.tests.module.

Hold tight for the next installment, which will include mocking in Javascript and introduce the Rhino runner. Happy coding!

// Instantiate widget class
var w = new core.widget.MyWidget();
 
// Decorate the original "method1" function
var _old_method1 = dojo.hitch(w, w.method1);
w.method1 = function(param) {
    var out = _old_method1(param);
 
    // Decorations
    if (param == 'foo' || out == 'bar') {
        console.log('calling method2 as result of method1');
        this.method2('baz');
    }
};

A few key points:

• dojo.hitch – used to provide proper context to the base “method1″, so that if anything relies on “this.” it will be handled as expected
• The decorations can be applied either before or after the base method is called. In the example, I chose to apply them after the base method to enable reaction based on the output.

You may notice that this is a much uglier implementation than the coffee and condiments example in the linked Wikipedia article. The wrap-add-and-return methodology didn’t work for me due to some class complexities and black magic. There may be a better way, perhaps even built into the dojo class wizardry, but this fit my use case well enough.

A coworker pointed out that Dojo now has the fancy shmansy dojox.aspect package to deal with this. And I found a great article detailing the new aspect wizardry in dojo. So my example could be revised using AOP, as follows.

// Instantiate widget class
var w = new core.widget.MyWidget();
 
// Create an aspect to wrap the method
dojo.require("dojox.lang.aspect");
var aop = dojox.lang.aspect;
aop.advise(w, 'method1', {around: function(param){
    var out = aop.proceed(param);
 
    // Decorations
    if (param == 'foo' || out == 'bar') {
        console.log('calling method2 as result of method1');
        this.method2('baz');
    }
}});

For example, imagine you have a list of cars in your inventory.  When a user clicks on one of the cars, a request is shot back to determine price, color, inventory stock, and description before displaying it.  If a user clicks on the VW Jetta, then quickly changes their mind and clicks on the Mazda 3, what would happen?  We’d expect the VW Jetta to be forgotten about and the data to be displayed for the Mazda.  But with all the randomness on the internet, if the 2nd request was quick to be returned from the server, while the 1st got delayed, a poorly designed app would display the Mazda, later receive the callback from the Jetta and overwrite the good results with the one the user had already forgotten about.

We could imagine 2 scenarios for how to stop the possibility of timing issues producing inconsistencies.

1. Block all future car clicks until the initial car click is loaded.  Ugh.  Terrible user experience.
2. When a car is clicked, see if any pending cars are being queried.  If so, cancel them, and query the new one.

How do we make this happen in Dojo 1.0 world?  Simple.  Use the cancel() method given back by the deferred xhr object.

1
2
3
4
5
6

this.doSingleXhr = function() {
    if (this._xhr) {
       this._xhr.cancel();
    }
    this._xhr = dojo.xhrGet(args);
}

Almost done.  The one hangup you might see is that the cancel() method does trigger the error() callback if you have one defined in your xhrGet.  Luckily, we can inspect the dojoType of the args given to the callback to determine if it’s the result of a cancel and ignore it.

1
2
3
4
5
6
7
8
9
10
11
12

this.doSingleXhr = function() {
    if (this._xhr) {
        this._xhr.cancel();
    }
    this._xhr = dojo.xhrGet({
        ...
        error: function(args) {
            if (args.dojoType=='cancel') { return; }
            handleError();
        }
    });
}