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;
 
})();

Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.

I had previously only used it as a session inspector — to review requests and responses as they occurred in the wild. As it turns out, you can modify request and response headers very easily.

For a quick example, let’s see what it would take to disable connection keep-alive’s when cache-control is set to no-cache. Fire up Fiddler, click Rules, then click “Customize Rules…”. It will pop open CustomRules.js, a JScript file with a Handler class. Scroll down to the OnBeforeResponse static function.

Just after the m_DisableCaching block that is probably already defined, let’s add a simple clause:

if (m_DisableCaching){
    oSession.oResponse.headers.Remove("Expires");
    oSession.oResponse["Cache-Control"] = "no-cache";
}
 
if (oSession.oResponse["Cache-Control"] == "no-cache") {
    // Disable keep-alive by setting Connection: close header
    oSession.oResponse["Connection"] = "close";
}

Fire up IE, visit a page, and look at the Fiddler session logs to see the difference. That easy. Have fun playing with headers!

On a side-note: thank God for Wordpress auto-save. Not that I had much in this article, but I “tabbed” out of the text editor accidentally, hit backspace (forcing the browser to go back), and cursed at the keyboard. Luckily, it was sitting 95% complete in my drafts folder!

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');
    }
}});

• Port MockMe to the Dojo javascript framework
• Utilize browser history sniffing to build a generalized user segmentation framework
• Write a Ubiquity plugin for spreeder (to easily speed read a page in Firefox)
• Port OWASP’s AntiSamy project to Python, to provide comprehensive XSS protection

None of these are terribly difficult to get started, and with the summer winding down, I might have a few minutes of free time to start working on some.

Sniffer browser history is something I’ve never thought of or heard of until reading Niall Kennedy’s post, which apparently he talked briefly about a few years earlier. The idea is that one could list a bunch of known URLs as links on your page. Then after applying unique a:normal and a:visited styles to them, you can read the computed style values on each link through the DOM. If the color (for example) changes to the a:visited style that you read through javascript, you now know that the user visited that site, and can make other layout changes accordingly.

Even without javascript sniffing per-se, you could apply the same technique. Think of this, if we want to do something if the user’s a yahoo user vs a google user, do this:

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

<style>
a#goog, a#yh {
    display: none; /* hide if user hasn't been there */
}
a#goog:visited, a#yh:visited !important {
    display: inline; /* make sure user sees search engine option if they've been there before */
}
</style>
<div>
  <a href="http://www.google.com" id="goog" onclick="doGoogle()">search via google</a>
  <a href="http://www.yahoo.com" id="yh" onclick="doYahoo()">search via yahoo</a>
</div>

Niall does have an excellent library started for browser sniffing. One great feature is that it allows you to configure a set of URLs that correspond to an application (for example www.facebook.com, facebook.com, profile.facebook.com, etc).

Some immediate applications include using the mapping service user is most comfortable with for directions to your business, displaying only necessary social bookmarking “add to” icons, and searching via user’s preferred search engine.

From the article:

Easily recognized branding such as “Add to My Yahoo” has yielded much higher conversion rates than a simple Atom link with a minimal effect on page load performance. Dynamically checking for active usage of 50 or so aggregators allows me to extend my total test list and promote an obscure tool that might never make the cut for permanent on-screen real estate.

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();
        }
    });
}