Admittedly, I am not that big a fan of Omniture. Their SiteCatalyst reporting application is slower than Google Analytics and not as flexible as it could be. My biggest gripe is their tracking JavaScript code, it’s just plain terrible. It’s slow, obfuscated (really? why do this?), bloated, impossible to debug and not built using modern practices. Oh, and they’re also insanely expensive if you want to get at all fancy.

This article is simply a straight how-to for building a custom link tracking JavaScript in the hopes that I can save some other JavaScript developer out there the headaches and tears usually associated with learning advanced Omniture implementations.

Omniture basics

The Omniture JavaScript does all of its work through the s object. This object has many different methods and properties that are all ingeniously designed to confuse and torment would-be implementers.

For custom tracking metrics you will be using prop codes, which are called “Custom Insights” in the SiteCatalyst reporting software. You associate a specific prop code to a specific piece of data. So you may associate s.prop1 to be the category of a product and s.prop2 to be the name of the product.

The way we track is by loading up prop variables with strings then telling the Omniture code to run. This is done by calling s.t() for a pageview track or s.tl() for a link click track.

How to track a click action with custom prop data

The code to track an action is actually quite simple, loading prop values and calling the tracking method. Here is what a tracking script looks like. This example is the basic custom click tracking code that you would expect to see in an onclick event attached to an anchor tag.

s.linkTrackVars = 'prop1,prop2';
s.linkTrackEvents = 'None';
s.prop1 = 'Televisions';
s.prop2 = 'Samsung - LN40B530 - 40" LCD TV - 1080p (FullHD)';
s.tl(this, 'o');

Now, this is fairly self-explanatory, but I’ll break this down line for line so you know exactly what’s happening and what these statement mean.

• s.linkTrackVars declares which prop codes you will be using in this event. This property is a comma-separated list of each prop code that you want tracked.
• s.linkTrackEvents are the “events” that an action may represent. Usually you will use events like “purchase” or “save” but you can put just about anything you want in here. It’s just a different way of looking at the same information. I typically set it to none and use custom insights for reports.
• s.prop1 and s.prop2 are the custom metrics that will be attached to this click event. In this case prop1 is the product category and prop2 is the product name.
• s.tl(this, ‘o’) calls the tracking action. The tl() method (a.k.a. the trackLinks method) requires two parameters, this anchor object to be tracked (should always be this) and the type of link we are tracking. There are three types of basic links that is method understands: o is the “Other/General” link type, d is a “File Download” link, and e which is an “Exit Link”. Anything that isn’t a download or exit link should be given the o tag.

There you have it, not incredibly complex, but not obviously simple either. There are a bunch of other properties that you can attach to a trackLinks event, but this is what 99% of them look like.

Building a script to attach link tracking events automatically

There are two standard ways to attach these custom link tracking events to the anchors that you want to track: the stupid method, and the smart method.

• The stupid method is the most common. This involves adding an onclick tag to every anchor and filling it with the appropriate code.
  • Pros: Stupid, simple, always works
  • Cons: Stupid, unmaintainable, ugly, increases markup, adds non-semantic markup
• The smart method is to build a single script that will attach the code to every link you want to track automatically on page load.
  • Pros: Smart, not-stupid, simple, maintainable
  • Cons: Links don’t get the tracking events attached until the whole page has finished loading.

For this rest of this article I will assume that you want to use the smart method. Basically, we will build a script that will look at every single anchor tag in the DOM and attach the click tracking events to any links matching whatever criteria you choose. This script will automatically run when the page loads.

Defining the criteria and search pattern

First off, you must be able to identify the links that you want to track. I have used two different systems for this: Searching href tags and adding rel tags.

Searching href tags is generally the best option. This means matching the link href and attaching the event based on that data. However I have found situations where I didn’t want to track every link that had the string “products.aspx” in it, so I chose to add rel tags to those links that I did want to track. This way I could just search for links that had rel=”product” in them.

The technique is still basically the same, we will gather all of the anchors in the document into an array, then iterate through the array, attaching the appropriate events and data to those anchor which meet our criteria for each type of page.

The basic script structure

No matter what you choose as your search criteria and trackable data you will need a script that has at least the following features:

• Iterates through all anchors on a page
• Allows you to attach tracking events without overriding any existing events
• Automatically runs as soon as the page loads
• Highly optimized for minimum execution time
• Cannot throw an error that will break the page
• Unobtrusive design that doesn’t have any dependencies (other than Omniture)
• Namespaced in object literal notation so that it can never have any confilcts

The basic JavaScript object that I use for this

// Omniture click tracking
// http://stevenbenner.com/2010/03/custom-link-click-tracking-using-omniture/

if(!sb_trackLinks) { var sb_trackLinks = new Object(); };

sb_trackLinks = {
	// initialize the click-tracking system and attach events
	init: function() {
		// verify that we are running in a modern browser, if not give up silently
		if (!document.getElementsByTagName) return false;

		// iterate through all of the links in the document
		var anchors = document.getElementsByTagName('a');
		for (var i=anchors.length-1; i>=0; i--) {

			// SEARCH STATEMENTS AND TRACKING VARIABLE BUILDING GOES HERE

		};
	},

	// tracking function
	track: function(obj, propCodes, linkType = 'o') {
		s = s_gi(s_account);
		// reset tracking properties
		s.linkTrackVars = '';
		s.linkTrackEvents = 'None';
		// iterate through each property in propCodes
		for (code in propCodes) {
			s.linkTrackVars += code + ','; // build the CSV list
			s[code] = propCodes[code];     // attach the prop code
		}
		// track it
		s.tl(obj, linkType);
	};

	// non-breaking/non-overriding/cross-browser event attachment
	addEvent: function(obj, evType, fn, useCapture) {
		if (obj.addEventListener) {
			obj.addEventListener(evType, fn, useCapture);
			return true;
		} else if (obj.attachEvent) {
			var r = obj.attachEvent('on' + evType, fn);
			return r;
		} else {
			obj['on' + evType] = fn;
		};
	}
};

// auto-init on load
sb_trackLinks.addEvent(window, 'load', sb_trackLinks.init);

This is the basic outline of my JavaScript click tracking object. It has three methods and automatically runs itself in the window.onload event.

I've put a lot of thought into optimizing this script. For instance, notice that I reverse iterate through the anchors array. This technique has been proven to be faster because the array length is only calculated once when the for statement begins. If you do the while i<array.length style then the length is calculated once for every iteration in the loop.

When you build any kind of tracking or analytics JavaScript your highest priority should be to shave every nanosecond from it's operations. It is acceptable to sacrifice readability for performance here. After all, as a web developer your primary job should be to improve user experience, tracking scripts are a necessity but do not benefit users in any way, so you do your best to reduce their impact on user experience.

The sb_trackLinks methods

There are three methods in the sb_trackLinks object:

init()

The init() method is where the startup, initialization and event attachment will occur. We still need to build the search criteria, tracking variables and event attachment code before this will do anything.

track(obj, propCodes, linkType)

The track() method is the code that will be attached to the onclick events for the anchors that we want to track. It requires two parameters and will accept a third.

• obj: The first parameter is the anchor object that we will be tracking, in the context of our for statement in the init() method this will always be anchors[i].
• propCodes: The second parameter is an object with the prop codes that we want to use. This should be a standard JavaScript object with the conventions as the s.propXX codes. So if you want to track prop1 you should set propCodes['prop1'] to the value that you want and pass it through to the track() method.
• linkType: The third parameter is the link type that will be passed to s.tl() and is optional. It will default to 'o'. As I said earlier, it will accept o, d and e as valid values.

You may have to modify this function if your Omniture code has been customized.

addEvent(obj, evType, fn, useCapture)

The addEvent() method is the standard addEvent that you see everywhere on the internet.

Crafting the search and tracking variables

Now that we have a basic structure that we can use, all that we need to build is the anchor search statements, tracking variable and event attachments.

This needs to be custom built for your specific needs. The application, URL structure and tracking needs are all critical parts of this equation. If you are using friendly URLs and need to parse data from them then you will may have to deconstruct the URI to grab the specific data that you want to track in prop codes. If you need data from somewhere else on the page you will have to figure out out to grab it. Etcetera.

I'll provide you with an example based on our previous examples. In this case we are tracking clicks in an online store application. We are using standard query string parameters in our URLs and do not need any other special data.

This is what our for statement will look like for this site:

for (var i=anchors.length-1; i>=0; i--) {
	// parse the query string into an object
	var queryString = {};
	anchors[i].href.replace(
		new RegExp("([^?=&]+)(=([^&]*))?", "g"),
		function($0, $1, $2, $3) { queryString[$1] = $3; }
	);

	// conditionals to match link href targets
	if (anchors[i].href == 'http://your.domain/' || anchors[i].href.indexOf('home.aspx') > -1) {
		// home page
		sb_trackLinks.addEvent(anchors[i], 'click', (function() {
				return function() {
					try {
						sb_trackLinks.track(
							this,
							{
								'prop1': 'home'
							}
						);
					} catch(e) {}
					return true;
				};
			})()
		);
	} else if (anchors[i].href.indexOf('category.aspx') > -1) {
		// category pages
		sb_trackLinks.addEvent(anchors[i], 'click', (function(catId) {
				return function() {
					try {
						sb_trackLinks.track(
							this,
							{
								'prop1': 'category',
								'prop2': catId
							}
						);
					} catch(e) {}
					return true;
				};
			})(queryString['category_id'])
		);
	} else if (anchors[i].href.indexOf('product.aspx') > -1) {
		// product pages
		sb_trackLinks.addEvent(anchors[i], 'click', (function(catId, productId, productName) {
				return function() {
					try {
						sb_trackLinks.track(
							this,
							{
								'prop1': 'product',
								'prop2': catId,
								'prop3': productId,
								'prop4': productName
							}
						);
					} catch(e) {}
					return true;
				};
			})(queryString['category_id'], queryString['product_id'], queryString['product_name'])
		);
	};
};

This is a bit technical, and uses some advanced JavaScript techniques. However, it should be fairly understandable if you know your way around JavaScript.

Since we need to grab query string values for most of our tracked pages I start off by parsing the query string into an object.

I then proceed down a list of if statements that try to match a specific page. Inside each if statement I attach an onclick event to the current anchor. That event passes our current data down through the JavaScript scope via a (function(v){})(data) statement. Inside that event I call the track() method with the data and return true so that the browser follows the link once the code as been executed.

This can get very long indeed if you have a lot of different types of pages in your web application that need click tracking. As always, order your if statements by commonality, putting the most commonly matched statements first. The script engine will have to fail every if check to get to the last statement. This minor optimization may save you a millisecond or two.

It is very important that you wrap all of the code inside the event in a try{}catch(e){} just in case something somewhere breaks. If you do not do this then the links on your site will stop working if anything goes wrong. There is nothing quite as asinine as links not working because the tracking script is broken.

Putting it all together

Now that we've built the search and attach code all we have to do is insert it into our base script. The result looks like this:

// Omniture click tracking
// http://stevenbenner.com/2010/03/custom-link-click-tracking-using-omniture/

if(!sb_trackLinks) { var sb_trackLinks = new Object(); };

sb_trackLinks = {
	// initialize the click-tracking system and attach events
	init: function() {
		// verify that we are running in a modern browser, if not give up silently
		if (!document.getElementsByTagName) return false;

		// iterate through all of the links in the document
		var anchors = document.getElementsByTagName('a');
		for (var i=anchors.length-1; i>=0; i--) {
			// parse the query string into an object
			var queryString = {};
			anchors[i].href.replace(
				new RegExp("([^?=&]+)(=([^&]*))?", "g"),
				function($0, $1, $2, $3) { queryString[$1] = $3; }
			);

			// conditionals to match link href targets
			if (anchors[i].href == 'http://your.domain/' || anchors[i].href.indexOf('home.aspx') > -1) {
				// home page
				sb_trackLinks.addEvent(anchors[i], 'click', (function() {
						return function() {
							try {
								sb_trackLinks.track(
									this,
									{
										'prop1': 'home'
									}
								);
							} catch(e) {}
							return true;
						};
					})()
				);
			} else if (anchors[i].href.indexOf('category.aspx') > -1) {
				// category pages
				sb_trackLinks.addEvent(anchors[i], 'click', (function(catId) {
						return function() {
							try {
								sb_trackLinks.track(
									this,
									{
										'prop1': 'category',
										'prop2': catId
									}
								);
							} catch(e) {}
							return true;
						};
					})(queryString['category_id'])
				);
			} else if (anchors[i].href.indexOf('product.aspx') > -1) {
				// product pages
				sb_trackLinks.addEvent(anchors[i], 'click', (function(catId, productId, productName) {
						return function() {
							try {
								sb_trackLinks.track(
									this,
									{
										'prop1': 'product',
										'prop2': catId,
										'prop3': productId,
										'prop4': productName
									}
								);
							} catch(e) {}
							return true;
						};
					})(queryString['category_id'], queryString['product_id'], queryString['product_name'])
				);
			};
		};
	},

	// tracking function
	track: function(obj, propCodes, linkType = 'o') {
		s = s_gi(s_account);
		// reset tracking properties
		s.linkTrackVars = '';
		s.linkTrackEvents = 'None';
		// iterate through each property in propCodes
		for (code in propCodes) {
			s.linkTrackVars += code + ','; // build the CSV list
			s[code] = propCodes[code];     // attach the prop code
		}
		// track it
		s.tl(obj, linkType);
	};

	// non-breaking/non-overriding/cross-browser event attachment
	addEvent: function(obj, evType, fn, useCapture) {
		if (obj.addEventListener) {
			obj.addEventListener(evType, fn, useCapture);
			return true;
		} else if (obj.attachEvent) {
			var r = obj.attachEvent('on' + evType, fn);
			return r;
		} else {
			obj['on' + evType] = fn;
		};
	}
};

// auto-init on load
sb_trackLinks.addEvent(window, 'load', sb_trackLinks.init);

Save this code in the s_code.js (or whatever you named it) script for your Omniture-enabled web site and it will start sending click data back to your Omniture account.

Gotchas

There are some possible problems that may crop up using this system.

• Page never stops loading
  I have seen pages that simple never stop loading because of poor use of AJAX, slow servers, or broken dependencies. The click tracking events will not be attached to links until the loading icon in the browser stops.
• Links added after page load
  If there are any links that are created after the page load event is fired, such as AJAX widgets or dynamic links, then they will not exist when this script is run and therefor will not have any tracking events attached to them.
• Omniture conflicts
  There have been several occasions where I've seen people try to use two (or more) instances of Omniture on the same page. If you have to deal with this then you need to modify the track() method to use your account name.
• 500ms link delay
  The s.tl() function has a half-second delay built into it. This is because the tracking data is sent by requesting a 1 pixel web beacon from the Omniture servers and the script needs to give the browser enough time to send the request. Unfortunately, this also adds an annoying delay to every link that you attach tracking code to.

Advanced tracking (more than just links)

Omniture link tracking can be used for more than just links. You can use the s.tl() method to send any data at any time for any reason. Do you want to track when someone puts their mouse over an image, or how long they waited before scrolling, or even what text they selected? You can do all of that, and more if you really want to.

If you ask me those fine-grain viewer eyeball focus type of reports are not only invasive but genuinely useless. However, I've been asked to do even worse invasive and pointless tracking before. If you need to you can send any data you want on any DOM event, or even with timers.

The only thing that you must overcome is that the object you pass to s.tl() must be an anchor, or more specifically, something with an href attribute. There is nothing about this in the documentation, but it simply doesn't seem to work unless it has an anchor with an href passed to it. You can get around this by creating an element or simply passing true.

This is, however, the subject of a different article.

Conclusion

As you can see it's not that difficult to implement custom link tracking with Omniture and you can get some very powerful reports without that much work. I still cannot give my glowing stamp of approval for Omniture as a reporting solution, for various reasons, but if you are using it then hopefully this tutorial will save you some time and headaches.

If you have any questions or comments please leave them in the form below and I will do my best to answer them. You can also take a look at the Custom Link Tracking post in the Omniture blog. It's a year old, but the author is still responding to questions.

Related articles

• AddThis: friendly widget and brilliant viral tracking scheme
• External templates for the DataView control: Microsoft Ajax Library 4.0
• JavaScript regex trick: Parse a query string into an object
• EXSLT set:distinct in MSXML for Internet Explorer
• Friendly URLs in an ASP.NET app

Here is a really sweet way to parse the query string into a JavaScript object with two lines of code using regular expressions to populate an object. I discovered this trick a few years ago and filed it away in my code snippets folder.

The Code

The JavaScript code itself uses the replace() method with a regular expression to target the name/value pairs in the URI string that you are working with. The replace value is actually a function which will be executed for each pair. This little function simply pushes the name/value pair into the queryString object.

var queryString = {};
anchor.href.replace(
	new RegExp("([^?=&]+)(=([^&]*))?", "g"),
	function($0, $1, $2, $3) { queryString[$1] = $3; }
);

Isn’t it beautiful? In this example anchor is some anchor tag on a page that I have already defined with a document.getElementById. However it works just as well with window.location.href.

Using it

Using this simple trick you can access query string parameters by saying queryString['name']. Let’s say that your URI looks like this:

http://your.domain/product.aspx?category=4&product_id=2140&query=lcd+tv

Want that product ID? Simple, queryString['product_id'] will return “2140″. Nice and simple.

If the query string parameter that you are searching for does not exist then it will return undefined without throwing an error.

Full example

Copy and paste this into your Firebug console and run it to see it in action:

var uri = 'http://your.domain/product.aspx?category=4&product_id=2140&query=lcd+tv';
var queryString = {};
uri.replace(
	new RegExp("([^?=&]+)(=([^&]*))?", "g"),
	function($0, $1, $2, $3) { queryString[$1] = $3; }
);
console.log('Product ID: ' + queryString['product_id']);     // Product ID: 2140
console.log('Product Name: ' + queryString['product_name']); // Product Name: undefined
console.log('Product Category: ' + queryString['category']); // Product Category: 4

Related articles

• Custom link click tracking using Omniture
• Optional parameters and named parameters in C# 4.0
• AddThis: friendly widget and brilliant viral tracking scheme
• External templates for the DataView control: Microsoft Ajax Library 4.0
• Must-have Firefox Add-ons for Web Developers & Designers

If you want to have a default set of arguments for a function or constructor then you have to create several overloaded versions of the function for each possible set of parameter that you want to be able to accept.

This will no longer be the case in C# 4.0 with the addition of optional parameters and named parameters features. This is one little change I am really looking forward to in a big way.

Traditional overloads

The use of good old fashioned overload functions isn’t going to be completely replaced by the new optional parameters system, but you will almost never need them again.

Here is an example of how we currently do default parameters:

static string test(int foo)
{
	return test(foo, "The value is {0}", false);
}

static string test(bool bar)
{
	return test(1, "The value is {0}", bar);
}

static string test(int foo, string blah)
{
	return test(foo, blah, false);
}

static string test(string blah, bool bar)
{
	return test(1, blah, bar);
}

static string test(int foo, string blah, bool bar)
{
	if (bar)
	{
		return String.Format(blah, foo);
	}
	else
	{
		return String.Format(blah, foo + 5);
	}
}

This is a lot of code for very little work. In fact, this doesn’t even cover all of the options, but I shortened it for this article. However this is how us C# programmers have been doing it forever.

C# 4.0 default parameters

With the new default parameters feature in C# 4.0 you can set the default value for any argument. The syntax for this is identical to JavaScript and couldn’t be simpler, arg = default.

Using this you can refactor the above functions into one short and readable function:

static string test(int foo = 1, string blah = "The value is {0}", bool bar = false)
{
	if (bar)
	{
		return String.Format(blah, foo);
	}
	else
	{
		return String.Format(blah, foo + 5);
	}
}

I absolutely adore this syntax. Like I said it is identical to JavaScript and is so much leaner and meaner. Improved readability always means improved maintainability.

C# 4.0 named parameters

This is all well and great, but the default parameters feature alone cannot replace the overload system. What if you want to skip an argument in the parameters list?

Named parameters to the rescue! This feature allows to you specify names and values when calling a function. Again, the syntax couldn’t be simpler, name: value.

This means that we can call that function with any parameters we want, in any order. For example:

test(foo: 3, bar: true);

Parameter order does not matter when using this syntax, the parameter name is all the information needed to attach the value. You can even mix named parameters with regular arguments.

test(15, bar: true, blah: "{0} is the value");

However, when mixing named parameters with regular parameters the named parameters must come after all of the regular parameters, and the regular parameters must be in the correct order.

Conclusion

This tiny, almost insignificant change will probably deprecate hundreds of lines of code in your average C# project. It will make functions and constructors much more readable and will make whole projects much more maintainable. It will reduce unneeded code and generally make your cs files shorter.

This single, tiny change is my single favorite upgrade to C# in 4.0.

Related articles

• Reporting of unhandled exceptions in your distributable .NET desktop application
• JavaScript regex trick: Parse a query string into an object
• Friendly URLs in an ASP.NET app
• External templates for the DataView control: Microsoft Ajax Library 4.0
• Firewall script tool for iptables

The idea of the reset style sheet is to globally target every markup element and set all of its possible attributes to zero, default or inherit. This gives the developer a “clean slate” with no browser default styles. Many say that this is the first thing you should add when you start building a web page, but I firmly disagree.

I’m sure that I am one of the small minority of web developers who’s saying this, but reset style sheets are bad practice, and it’s time to stop using them.

Why are reset style sheets so popular?

The trend of using a reset CSS wasn’t always so prevalent, not long ago they were practically unheard of. But in recent years the reset trend has absolutely exploded. Now every CSS framework and many large web sites use them as the base for everything they put on the web.

This happened because designers and developers were tired of dealing with the quirks of the different browsers. Just about every browser has a default set of styles that it applies to pages. 99% of these quirks could be remedied by globally setting margin and padding to zero.

However, this wasn’t enough for some. Designers working with forms and other browser/OS specific elements were tired of having to specifically reset every form element in CSS every time they started a new web site. So someone decided to make a single CSS file to specifically target and reset the CSS on every HTML element. Now all they have to do is link the reset CSS and never worry about it again.

This is quite a time saver, especially when working with forms. The technique gained popularity and eventually became a regular part of web development for many designers.

Why is using a reset CSS bad?

I am not saying that the technique is bad, I’m saying it’s bad practice, for numerous reasons.

Accessibility

Many reset style sheets set outline to zero. Outline is an important feature for usability and accessibility. It is used for keyboard navigation.

The outline property sets an overlay border on an active/selected element that is actionable and/or has a tabindex. This gives users a visual cue as to where there active cursor is (note: tab cursor, not mouse cusor). Without the outline users who cannot use a mouse or who choose to use the tab function to navigate pages can’t see where their cursor is. This effectively makes the page unusable for some disabled people, and less-usable for tabbing power-users.

Unnecessarily large style sheets

There are certain display standards and conventions that all browsers agree on by default. Headings are bold, links are underlined, lists have bullets, etcetera. When using a reset style sheet you have to manually set every single display property for every single element.

Why would you want to repeat the same CSS that every browser gives you by default? It only clutters your style sheet, increases download footprint and slows the browser rendering engine.

Inefficient inheritance and slow rendering

Styles are not simple text properties that are built into your operating system, they are rendering statements that are passed to a large and complicated rendering engine in the browser. This rendering engine must read all of the CSS and build the display rules for the entire page before it will even show you the content.

The browser default styles that reset style sheets are trying to kill will be the foundation of the inheritance tree regardless of what styles you put on top of it. So the rendering engine must add your rules on top of the reset rules, on top the default display rules. As a CSS coder it is your job to optimize your CSS to make this as fast and easy on the rendering engine as possible.

For example: you want h1 tags to be bold.

• Without a reset CSS you do not have to add any statements to accomplish this effect, it is part of the browser default. So the rendering engine only has to process the already optimized and compiled default to give you this effect.

  h1 { font-weight: bold; } /* Browser Default */

• With a reset CSS you will be sending not only the h1 reset, but probably the div, body and html reset along with your override, h1{font-weight:bold;}. So the rendering engine sees an inheritance tree that looks something like this:

  html {
  	font-weight: normal;
  	body {
  		font-weight: normal;
  		h1 {
  			font-weight: bold;
  		}
  	}
  }
  h1 { font-weight: bold; }  /* Browser Default */

You can actually see a view of this when you are looking at the CSS information in Firebug. This is a whole lot of extra work for the browser to have to work through to create your styles. Even if you didn’t want the default bold h1 then it would still be far more efficient to put h1{font-weight:normal;} in your CSS without the reset. After all, the default target is specifically overridden and the engine does not have to process the extra inheritance information.

The image above is an excellent example of what I’m talking about. It’s a worst-case situation where bad markup, bad styles and a reset CSS have all come together to produce a monstrosity. This is a real site that I’ve had to work on. Notice the scroll bar on the style list, because of the outrageous inheritance tree this one element has 30+ self-overridden reset selectors applied to it.

Granted, this example is an extreme case, however the effect is the same even when the site has excellent markup and well designed CSS.

Maintainability and debugging

I am a dedicated Firebug user. I love the tool and I simply cannot live without it for CSS development. But I hate working on pages that have reset styles because they clutter up the interface and I have to scroll through countless overridden selectors to find the one that is applied in each case.

Transmission footprint

A reset style sheet is yet another CSS file and a couple hundred more bytes that the browser has to download. The single most important aspect of web page and server optimization is reducing download size and reducing the number of connections needed to send a single page.

Page optimization is why we use image sprites and minified/combined include files now. Every connection and byte of data that you can remove will make your site faster and scale better. A large majority of the time spent downloading a web page is spent on the latency and over-the-wire transmit time for page dependencies and resources.

Take this very seriously, development on a high traffic web sites is all about shaving every millisecond and every byte you can because you will be able to support that many more simultaneous users.

That was a very long-winded rant, so how do you deal with it?

Simple, the way we’ve been doing it since we stopped using tables and 1px separator gifs.

* {
	margin: 0;
	padding: 0;
	/* possibly border: 0 */
}

This single statement at the top of your style sheet will give you almost the same effect as a reset style sheet with almost none of the drawbacks or performance degradation.

Asterisk is the global selector, it will target everything, regardless of type, standards or validity. It is also an efficient rule (when used on its own). Most rendering engines will understand that an asterisk select means everything, regardless of inheritance. So it doesn’t process it as an inheritance, it is simply attached to every element.

It is worth noting that asterisk when joined with another selector (e.g. #navigation *) is actually an inefficient selector because it does have to process an inheritance tree.

Conclusion

I understand that there are times when a reset CSS can be an asset, such as rapid prototyping and very extreme/artsy designs where you would have to override everything anyway. However for the sake of performance optimization and general best practices you should avoid reset style sheets.

Related articles

• Excessive JavaScript and AJAX: bad practice & broken pages
• AddThis: friendly widget and brilliant viral tracking scheme
• Must-have Firefox Add-ons for Web Developers & Designers
• Graceful degradation theory, IE and CSS3
• PHP needs an IDE and a membership provider

EXSLT functions are widely used and extensively tested. Not only is it available for every server-side XSLT engine, but it is also available in Mozilla Firefox, Safari, Chrome and Opera.

Unfortunately, as usual Internet Explorer throws a wrench in the whole works. Microsoft in their infinite wisdom decided not to implement the EXSLT functions and specs in their browser. Instead they implemented their own MSXSL extensions, which are frankly terrible. It doesn’t have anywhere near as much functionality as EXSLT and will never work with anything other than Internet Explorer.

The most common (and difficult to replicate) EXSLT function that I use is set:distinct. It is an extremely powerful function that lets you grab a distinct list of nodes, attributes, or values without impacting your current context in the style sheet.

This function is not available in any form in MSXML, so I decided to build it.

Building a custom function is MSXML

The MSXSL spec in MSXML does have one powerful feature that can help us rectify some of these problems, msxsl:script. This feature allows you to build script extensions inside your XSLT style sheet. Of course it only exists in the Microsoft spec, so really it’s only obvious use is spending weeks hand-crafting the standard extension functions that Microsoft decided that they didn’t need to support.

In this case I built a JScript hack to implement the set:distinct function. It isn’t nearly as powerful or flexible as the real EXSLT function, but it will grab a distinct list of nodes.

We have to use native MSXML XSLDOM scripting to do all of this and we have to return the results in the form of a NodeList so the the XSLT processor can process the output.

This is the script that I came up with:

this['distinct'] =  function (values) {
	// create an MSXML DOMDocument
	var xmlDoc = new ActiveXObject('Msxml2.DOMDocument.3.0');
	xmlDoc.async = false;
	xmlDoc.loadXML('<?xml version="1.0" encoding="utf-8"?>\n<distinctRoot></distinctRoot>');

	var dedupe = [];
	// iteratre through the nodes passed to this function
	var node = values.nextNode();
	while (node) {
		var isDuplicate = false;
		// does this node already exist in our dedupe array?
		for (var i=0; i<dedupe.length; i++) {
			if (dedupe[i] == node.xml) {
				isDuplicate = true;
				break;
			}
		}
		if (!isDuplicate) {
			dedupe.push(node.xml);
			// append this node to the DOMDocument
			xmlDoc.documentElement.appendChild(node.cloneNode(true));
		}
		node = values.nextNode();
	}
	var tagName = xmlDoc.documentElement.childNodes[0].nodeName;
	return xmlDoc.documentElement.getElementsByTagName(tagName);
}

We will run this script inside a <msxsl:script language="JScript" implements-prefix="set"> statement. Notice the implements-prefix attribute, this tells the MSXML engine that this block of code will define the “set” namespace. In the code we attach a function to this['distinct'], so when we call “set:distinct” in the XSLT it will call this function.

This script is not perfect, and it is no where near a full implementation of the EXSLT set:distinct function. Here are the major limitations:

• Only works on NodeLists. It will not be able to return a distinct list of attributes, values, text nodes, etc. There might be a way to do those in JScript, but I couldn’t find one.
• Only one kind of node. If you want a single distinct list of <authors> it will work, however if you want a single distinct list of <authors> and <writers> it will not work.

Important note: Do not use msxsl:script in server-side XSLTs in .NET. There have been numerous problems reported in .NET 2.0 that will case fatal memory leaks. It works fine in web browsers, just don’t use this tag in the XslTransform or XslCompiledTransform classes.

Implementing the set:distinct hack

Getting this code to work is actually quite simple once we’ve built the function. All you have to do is paste the code into the XSLT and tell the style sheet to exclude the set and msxsl prefixes. But I’ll provide a demonstration so you can see a real world working example.

First off: a sample XML file for us to show the use and purpose of the set:distinct function.

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="layout.xsl"?>
<searchresults>
	<book id="21">
		<title>Advanced XSLT</title>
		<author id="2">Steven Benner</author>
		<releasedate>February 2010</releasedate>
	</book>
	<book id="142">
		<title>XSLT</title>
		<author id="5">Doug Tidwell</author>
		<releasedate>August 2001</releasedate>
	</book>
	<book id="15">
		<title>XSLT and XPath On The Edge (Professional Mindware)</title>
		<author id="3">Jeni Tennison</author>
		<releasedate>July 2005</releasedate>
	</book>
	<book id="92">
		<title>Blood, sweat and tears. The XSLT experience.</title>
		<author id="2">Steven Benner</author>
		<releasedate>January 2010</releasedate>
	</book>
	<book id="103">
		<title>Beginning XSLT 2.0: From Novice to Professional (Beginning: from Novice to Professional)</title>
		<author id="3">Jeni Tennison</author>
		<releasedate>October 2001</releasedate>
	</book>
</searchresults>

I want to build a list of books grouped by author. Each author should have his or her section with their books displayed under their name.

Now we’ll create the full XSLT style sheet to implement this functionality.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:set="http://exslt.org/sets"
	xmlns:msxsl="urn:schemas-microsoft-com:xslt"
	exclude-result-prefixes="set msxsl">

	<!-- the msxsl script for our custom set:distinct -->
	<msxsl:script language="JScript" implements-prefix="set">
	<![CDATA[
		this['distinct'] =  function (values) {
			// create an MSXML DOMDocument
			var xmlDoc = new ActiveXObject('Msxml2.DOMDocument.3.0');
			xmlDoc.async = false;
			xmlDoc.loadXML('<?xml version="1.0" encoding="utf-8"?>\n<distinctRoot></distinctRoot>');

			var dedupe = [];
			// iteratre through the nodes passed to this function
			var node = values.nextNode();
			while (node) {
				var isDuplicate = false;
				// does this node already exist in our dedupe array?
				for (var i=0; i<dedupe.length; i++) {
					if (dedupe[i] == node.xml) {
						isDuplicate = true;
						break;
					}
				}
				if (!isDuplicate) {
					dedupe.push(node.xml);
					// append this node to the DOMDocument
					xmlDoc.documentElement.appendChild(node.cloneNode(true));
				}
				node = values.nextNode();
			}
			var tagName = xmlDoc.documentElement.childNodes[0].nodeName;
			return xmlDoc.documentElement.getElementsByTagName(tagName);
		}
	]]>
	</msxsl:script>

	<!-- set output mode as html -->
	<xsl:output method="html"/>

	<!-- this key is used to sort the results, if you don't need
		to sort then you don't need a key -->
	<xsl:key name="authorIds" match="author" use="@id" />

	<!-- store the books in a variable because we loose
		context in the foreach -->
	<xsl:variable name="books" select="/searchresults/book" />

	<!-- template that matches the root node -->
	<xsl:template match="searchresults">
		<html>
		<head>
			<title>Demo</title>
		</head>
		<body>
			<h1>Results by author</h1>

			<!-- for each unique author id -->
			<xsl:for-each select="set:distinct(book/author)">

				<!-- sort by author name -->
				<xsl:sort select="key('authorIds', @id)" order="ascending" />

				<!-- store the current id in a variable so we can use
					it for selects -->
				<xsl:variable name="authorId"  select="@id" />

				<h2><xsl:value-of select="key('authorIds', @id)" /></h2>
				<dl>
					<!-- run the book template on every book
						with this author -->
					<xsl:apply-templates select="$books[author/@id=$authorId]">
						<!-- sort by book name -->
						<xsl:sort select="title" order="ascending" />
					</xsl:apply-templates>
				</dl>

			</xsl:for-each>

		</body>
		</html>
	</xsl:template>

	<!-- template that matches books -->
	<xsl:template match="book">
		<dt><xsl:value-of select="title" /></dt>
		<dd>
			<xsl:value-of select="author" /> / <xsl:value-of select="releasedate" />
		</dd>
	</xsl:template>

</xsl:stylesheet>

Note the exclude-result-prefixes statement. This tells the XSLT engine that it should not render anything with these namespaces. So Firefox, Safari, Chrome, etc. will completely ignore the msxsl blocks.

This XML and XSL pair works in all modern browsers including the not-so-modern IE6.

Check out the working demo for a proof of concept.

Conclusion

As usual, Internet Explorer sucks. Microsoft’s unwillingness to adopt the same standards that every other browser lives by is hurting the internet. However, it is possible to work around some of the missing functionality. It’s just really painful and requires you to learn Microsoft specific technologies and language implementations that will never see the light of day for 60% of your users.

This particular solution is completely cross-browser compatible. Every EXSLT enabled browser will ignore the msxsl namespace and use it’s built-in set:distinct function. Internet Explorer will evaluate the script and run our custom set:distinct function.

Related articles

• Publishing XML to the web with XSLT: a replacement for the presentation layer
• Custom link click tracking using Omniture
• Friendly URLs in an ASP.NET app
• External templates for the DataView control: Microsoft Ajax Library 4.0
• Reporting of unhandled exceptions in your distributable .NET desktop application

However, in the latter half of 2008 AddThis was acquired by Clearspring, an online media company. They were able to see the value in having a glorified tracking bug on hundreds of thousands of sites across the internet. It’s grown to such an extent that Clearspring now sees what half of the internet is doing.

I’m no tinfoil hat paranoid, but I was a bit surprised at the scale and power of this system. Personally I congratulate them on their wild success. It was a brilliant idea and has become an internet phenomenon. However, I have no interest in giving Clearspring information on my visitors (for free).

So lets reduce it’s tracking ability with a couple lines of JavaScript.

Neutering the AddThis widget (a little)

You can greatly reduce their tracking abilities by adding two simple configuration options to the AddThis settings.

var addthis_config = {
	data_use_cookies: false,
	data_use_flash: false
}

The first statement, data_use_cookies is fairly obvious, it turns off the AddThis cookies. However many web users who are concerned about their privacy have already taken to limiting or disabling cookies altogether. There is however an ingenious workaround that few people even know exists, the Local Shared Object (LSO) feature in Flash.

Local Shared Objects

LSOs are basically cookies, but their bigger and better in every way. Flash LSOs do not expire and can hold much more data. Most importantly, they are almost never deleted by users. The only way to control them is through the Global Storage Settings control via Adobe’s Flash configuration on their web site, or with the BetterPrivacy Firefox add on.

If you’re in the business of analytics and tracking, LSOs are where it’s at. This is why we are setting data_use_flash to false. The widget itself has no reason to use flash, the only reason it is in there is because Clearspring wants to use LSOs to augment their tracking.

If you’re a Firefox user you can pick up the BetterPrivacy add on and get in-browser control of your LSOs. Like I said, I’m not a paranoid, but I do believe in protecting online privacy.

Does this really change anything?

No, not really. I don’t know the internals of their analytics system, but if they have any know-how whatsoever they can grab 95% of their analytics information from the tracking data provided by the widget JavaScript and logs. Removing the cookie tracking does however make it more difficult for their cross-domain tracking system to aggregate and collate user interests.

Conclusion

If you are concerned about your privacy online them only use Mozilla Firefox and pick up the BetterPrivacy and CookieMoster add-on’s (you need both). They will stop the simple cookie/LSO based tracking systems.

If you are concerned about the privacy of the visitors on your web site then do not use AddThis bookmarking widget. But if you really can’t come up with an alternative at least be sure to add the JavaScript code I posted above with your AddThis widget. ShareThis is an alternative, but they are hoping to cash in the same way.

In the end, you and your site’s visitors have little to no privacy when it comes to browsing habits. Google knows that you’re looking at my site right now. This isn’t something to be afraid of, but be aware that this is the way it works. As a web site administrator the best you can do is to not use content or tools provided by metrics or advertising companies. If you can you should replace AddThis with some simple icons and links, and if you have the resources, replace Google Analytics with Piwik. But that is too far even for me.

Related articles

• Custom link click tracking using Omniture
• Excessive JavaScript and AJAX: bad practice & broken pages
• JavaScript regex trick: Parse a query string into an object
• Reset cascading style sheets are bad practice
• External templates for the DataView control: Microsoft Ajax Library 4.0

But did you think about using it as a poor man’s CVS? It’s actually a really good solution for personal projects, or for a small group of people working on a project. I have fallen in love with the service for several reasons.

It’s free. Your free account will give you 2GB of storage to start, if you play their new user game or viral marking game then you can easily get 3GB on your free account, which is far more than you will ever use for source code. If you do end up needing more space, they offer pay subscriptions for 50GB and 100GB, costing $10/month and $20/month. Personally, I’m sticking with the free plan.

It’s fast. When I am actively working on a project my changes are uploaded and synced to my other computers in seconds with no performance impact on the computers. The system works by only sending the delta so it doesn’t upload an entire file every time it changes. It is even smart enough to sync over the network so it uses the least bandwidth.

It’s easy. I don’t have to worry about proper commits or forgetting to check something back in at 2am, when I save the file it is automatically synced up. Sure it’s not as advanced as a real repository, but it is just so simple. After all, do you really need branch and merge on your freelance project or web design?

It has versioning (kinda). Dropbox even has a versioning system, although it’s not designed for code. You miss out on nifty diff and blame tools. But on a small project you probably already know who to blame. Unfortunately they only keep versions and deleted files for 30 days unless you have a pay plan. I really wish they’d give that out for free.

Personally, I use dropbox as a personal VSS and backup for all of my projects. It is really nice to know that my work is backed up with some version info in one central location as well as distributed to all of my computers.

It’s an off-site backup. It is very important that you keep your hard work backed up. But just copying it to an external drive isn’t enough. You need to have an off-site backup in case something terrible happens. This is something else that dropbox does well.

The other option: If you don’t mind giving your code to anyone in the world who wants it, GitHub is still the free code repository of choice. You’ll learn to deal with the quirks of git after a while, though it does have a rather steep learning curve. However, if you want to keep your code private and want to have a lot of projects, GitHub will get pricey very fast. Since I don’t want to release the code for my personal stuff, GitHub just isn’t worth the cost for me. Personal projects are saved on dropbox, work projects are saved in the company’s VSS.

For big-project code work in a multi-developer environment dropbox will certainly not replace your CVS/VSS/SVN/GIT code repository. Having tools like diffs, branches and merges integrated into the repository is absolutely required in a corporate environment.  But for one man projects or freelance work where you can’t really justify the cost or the time for managing a real code repository, dropbox is a good choice.

Related articles

• Firewall script tool for iptables
• An IDE for PHP that doesn’t suck
• Must-have Firefox Add-ons for Web Developers & Designers
• Building a home Network Attached Storage server. Part 2: RAID Setup
• Reporting of unhandled exceptions in your distributable .NET desktop application

Just in case you don’t know what a friendly url is, “friendly URLs” (aka “Pretty URLs”, “Beautiful URLs”, “URL Rewriting”, “URL Mapping”, “SEO URLs”, etc.)  I am talking about pages or resources that are identified by keywords in a pseudo-directory structure. For Example, you have a web application with a search page. In a standard web forms application your URI will probably look something like this:

http://your.address/Search.aspx?query=friendly

In a friendly URL structure, your URI would look something like this:

http://your.address/search/friendly

This is a much leaner and cleaner looking link. Really better in every way, though if you are still using ASP.NET web forms you will have to go through some trouble to make your links look like that. As well as having to deal with maintaining the rules and code to support it. It may very well not be worth the trouble.

If your web application is consumer facing and relies on search engines for traffic then you should probably implement friendly URLs in some form for your app.

Using friendly URLs is by no means required. They have been proven to increase relevancy in search engines because the keywords in the URL adds weight to the result for any matching keywords. But this really is the only benefit that can be used to justify the time and maintenance it takes to deal with using friendly URL strings. If your web application is behind a login screen, or doesn’t need to be ranked in search engines then friendly URLs are probably not worth the trouble.

Options

You have a lots of options for implementing friendly URLs in your ASP.NET application. There are dozens of URL rewriting solutions for .NET out there, these are just the few that I have had real experience using.

Use MVC – its grrrrrrreat!

By very definition, ASP.NET MVC gives you great URLs without extra effort or maintenance issues. The MVC system uses the ASP.NET routing engine, a very nice solution which is integrated into the ASP.NET application life cycle. Since it’s integrated into .NET itself it is very fast and requires zero maintenance.

There are so many other reasons to use MVC that I wouldn’t even try to go over them in this post. Suffice it to say that I haven’t built a new web forms application since MVC 1.0 was officially released. As far as I’m concerned, this is the way ASP.NET should work.

If however, you must use web forms then you still have two other good solutions.

IIS 7 URL Rewrite Module

If you are running IIS 7 and have enough access on your server to add and manage IIS modules then the official IIS 7 URL Rewrite module is your best choice. It is fast, since it is directly integrated with IIS and it is official, so it’s fully supported.

• Official URL Rewrite Module Page
• URL Rewrite Module Forum

Implementing pretty urls with the IIS7 URL Rewrite Module is pretty straight forward. You have to install the module on the server then configure the site, either via the administration panel, or in the web.config.

Managed Fusion Rewrite library

This is another good solution. The Rewrite module from Managed Fusion is a DLL that you add to your project. It runs as an HttpModule that you configure in the web.config. It will pull your rewrite rules from a separate file that you specify in the web.config or you can set your rule in the web.config itself. This module uses standard Apache mod_rewrite syntax and commands .

It is a proprietary library, but has a nice open license so you can use it for personal or commercial purposes. It is reasonably well maintained and I have personally used it in very high traffic environments.

• Official Managed Fusion URL Rewriter Page
• Managed Fusion Rewriter at Codeplex
• Apache mod_rewrite documentation (syntax reference)

Implementing the Managed Fusion rewriter is actually very simple, especially if you are already familiar with Apache’s mod_rewrite syntax. You just need to reference the rewriter DLL in your project and build the rewriter rules. It’s all in one solution with no external dependencies so it’s easy to deploy and manage. You don’t have to mess with any IIS configuration.

Roll your own

If you have special needs, or are feeling bored, then sure, you can roll your own solution. I don’t recommend it. You don’t want to have to deal with every possible URL in code, nor do you want to build and maintain something hundreds of other people are doing already (maybe you can reinvent the wheel), it will just be a maintenance nightmare.

Implementation

Setting up a web forms application to implement a URL rewriting system is fairly straight forward, but will take some time and some serious thought.

Install rewriter. First off set up whatever rewriter solution you have chosen and verify that it is working. I gave you all of the links you’ll need to get them working already.

Define URL formats. Now you need to figure out exactly what format you will follow for urls. This planning step is unique to every application so I can’t give you much advice, except to say that you should focus on adding the important keywords. Do not pack the URL with too many keywords, you will get punished for keyword stuffing. Keep it simple, like /search/QUERY or /user/NAME.

In this example I will define the search URLs as:

/search/SEARCH_QUERY

/search/SEARCH_QUERY/PAGE_NUMBER

Build rewriter RegEx. The next step is to write the actual string statements that will match your new friendly url structure and extract the data that you need to pass the page. Basically all rewriter systems, including the IIS 7 URL Rewrite Module and the Managed Fusion Rewriter, use Regular Expressions to do the string matching and evaluation. There is an art to writing good regex statements. If you haven’t learned regex yet it’s never too late to start, you will find them useful throughout your career.

In this case I’ll be using the Managed Fusion Rewriter because I am so used to doing this kind of thing in apache. The MF Rewriter uses the same functions and syntax as apache’s mod_rewrite. For a good reference check out the Apache mod_rewrite documentation.

Here is an example rewriter file for our little search app running Managed Fusion.

# Initialize the rewriter
RewriteEngine On
RewriteBase /

# Search rules
########################

# Basic search rule
# matches "/search/some_search_query
RewriteRule ^/search/(\w+)$          /Search.aspx?query=$1          [NC,L]

# Search pagination rule
# matches "/search/some_search_query/2" (i.e. page 2)
RewriteRule ^/search/(\w+)/(\d+)     /Search.aspx?query=$1&page=$2  [NC,L]

Lets take a closer look at the rule on line 10:

• RewriteRule begins the statement telling the processor that this is a one-line rule. This statement has 3 arguments.
• ^/search/(\w+)$ is the regex that we are trying to match in the friendly url. Breaking it down the first character is a carrot ^ which means “begins with”. It is followed by the string “/search/” which is a literal string match. Next is (\w+) . \w is the “word” character, it means any alpha-numeric or basic symbol character. The + means “one or more”. That whole statement is wrapped in parentheses, which means “save this value so I can access it later”. The last character is the $ symbol, which means “ends with”. Putting it all together this regular expression reads “Begins with /search/, followed by, and ending with, one or more word characters. Save the word characters into $1″.
• /search.aspx?query=$1 is the rewritten url that we will evaluate the friendly url into. This is the real url that will be executed. The $1 means the first parentheses item from the first statement. They are in left-to-right order and can be nested as deep as you want.
• [NC,L] are the rule statements. In this case I am using “NC” which means “Not Case-sensitive” and “L” which means “Last”. So case has no effect on the match, and when it does match it stops processing the rewriter rules. If you don’t have the L statement then the rewiter engine will keep testing every rule that follows it, wasting processing power and possibly matching a rule further down that you didn’t want it to use.

Create a class to build your new URLs. Now that you know what your URLs should look like and have gotten them working, you need need to be able to link to them anywhere in the application. My solution for this is to build a class in the codebehind to handle creating the URLs. No matter what we do we will have to maintain URLs and support these changes in two places, the rewiter rules, and the UrlBuilder class. But this is better (and more maintainable) than custom crafting URLs every time you want to link them.

Here is an example class for our search application:

public class BuildUrl
{
	public string Search(string searchQuery)
	{
		return Search(searchQuery, 1);
	}

	public string Search(string searchQuery, int pageNumber)
	{
		if (pageNumber == 1)
		{
			return "/search/" + HttpUtility.UrlEncode(searchQuery);
		}
		else
		{
			return "/search/" + HttpUtility.UrlEncode(searchQuery) + "/" + pageNumber.ToString();
		}
	}
}

Now you can use this one central class throughout your project whenever you need to create a link. For example if you want to create a search link for “cars” all you have to do is say:

<a href="<%= BuildUrl.Search("cars") %>">Search for cars</a>

You will have to build a function for every type of link, but at least it’s easy to maintain.

Migration

If your web app is already running and is indexed by search engines or linked to by other sites then you will need to setup redirects for every page that you will be moving to a friendly URL. If you don’t then the pages will just 404 or error out. This means that any links to your pages will be broken and the page rank that they’ve earned will be dropped.

So it is indeed very important to properly redirect all old urls to the new ones, forever. By properly, I mean a HTTP 301 redirect. Status code 301 means “Moved Permanently”, this will tell search engines to update the URL, and browsers will cache the updated URL.

The most simple solution is to add a code block at the top of the page that tests for an old url, then builds and redirects to a new url.

Here is a little sample for what our search page redirect would look like:

string NewUrl = BuildUrl.Search(Request.QueryString["query"]);

if (Request.RawUrl.IndexOf("/search.aspx", StringComparison.OrdinalIgnoreCase) > -1 ||
	Request.RawUrl.IndexOf(NewUrl, StringComparison.OrdinalIgnoreCase) == -1 )
{
	Response.Status = "301 Moved Permanently";
	Response.AddHeader("Location", NewUrl);
	Response.End();
}

Pretty simple right? This needs to be custom made for each aspx page to match the new URL format, but it is a simple block of code.

Conclusion

It’s a bit of extra work and requires some thought to set up url beautification, but if your web app depends on people finding it through search engines then it’s probably worth the effort. Think very carefully about the URL structure you use. Once you deploy it to the internet it is very difficult to un-do. If you expect people to link to you then you have to support every url that has ever worked indefinitely.

Once you have it all setup it should keep working just as indefinitely. When you add a new page you will have to add some new rules and a new function to the UrlBuilder class but that is fairly easy. Just make sure you get your url structure right, the first time.

Though, if you are still planning your next app and know you want pretty urls, now it the time to take a good hard look at ASP.NET MVC and all of the wonderful tools and processes it brings to the table. I have fallen in love with MVC and will probably never make another web forms app. I will of course continue to support the ones that I have.

ScottGu has an old but probably better post than mine on his blog. If you’re thinking about implementing rewriting then you should read that one too.

Related articles

• External templates for the DataView control: Microsoft Ajax Library 4.0
• Reporting of unhandled exceptions in your distributable .NET desktop application
• Custom link click tracking using Omniture
• Optional parameters and named parameters in C# 4.0
• EXSLT set:distinct in MSXML for Internet Explorer

However few have heard of XSLT, a standard language adopted by the W3C a decade ago for styling XML data for user consumption. XSLT, or XSL Transform, is a real language, part of XSL, the XML Stylesheet Language. XSLT is a tool for reformatting XML data, literally an XML stylesheet. This powerful language lets you convert XML data into almost any other XML structure you could imagine, including completely valid and functional XHTML.

Simply put, if your web application has been built to produce XML for feeds or APIs, then you do not need to build another set of logic to make a web version. You can let web browsers hit the service, just as you would for feeds or APIs. Just create an XSLT and link it from your XML document. All modern browsers will render the XSLT and display it as a normal web page.

The most famous example of this technique in action is the World of Warcraft home page. Blizzard publishes a minimum amount of data in a XML document which includes a reference to an XSLT stylesheet. The XSLT takes this minimum of data and uses it to build the XHTML document in the users’ web browser. This means that instead of having a complicated and slow CMS solution they can serve the entire (very high-traffic) home page from flat text files. When they change the content, all they need to do is publish the tiny XML file with the new data. When they want to change the look and feel they simply change the XSLT file.

This provides a nice level of abstraction between the data and the layout. Your application can focus on data, leaving the work of presentation to the XSLT.

Applications

This technique may not be particularly well suited to your average web page, such as a company web site. Most standard web sites have no need for XML, so there is no structure to build or maintain it. But for a web application where you are going to be dealing with a lot of XML this is a great solution.

I would also argue that all XML feeds and APIs should have an XSLT stylesheet so they can render in a more user friendly view to people who want to open them directly in their browser. So if your API accepts search queries why not use an XSLT to format the results in a user friendly browser view, and add a little search form at the top.

Anywhere you send XML to the internet there is a good reason to attach an XSLT.

Benefits

Using XSLT to support and render your XML data can have many huge advantages, especially for a high-traffic web application.

Faster development. Why build a whole new layer of logic and functionality? You can work on making the best XML data returns and use XSLT as your visual layer.

Less server load. Scripting a whole web site on top of your current data layer adds overhead. Save the servers, publish your data directly with a flat text file and let the browser handle the heavy lifting.

More maintainable. XSLT is basically a template. I’ve mentioned this before, but I love templates. If you want to change the look and feel of your application all you have to do is modify the XSLT files. Once you’ve gotten proficient at XSLT you will find that in many cases it is easier to modify.

Browser support

All modern browsers support XSLT, even updated version of IE6. The original vanilla version of Internet Explorer 6 used the Microsoft XML Core Services (MSXML) 3.0 processor for its XSLT engine. This version of the MSXML processor didn’t support the full XSLT 1.0 specification released by the W3C, it only partially support an antiquated draft. It was also simply terrible in every way. Say “MSXML 3″ to an old XML guy and he’ll probably adopt the fetal position and begin rambling incoherent nonsense about the horrors he’s experienced.

Fortunately, it is exceedingly rare to find a copy of the original IE6 out in the wild. If the user has updated Windows, installed a service pack, or installed the Microsoft Office software, then their version of IE6 has been updated to use the MSXML 4.0 processor. MSXML 4.0 and up have excellent support for XSLT and are very fast at rendering it.

I don’t believe that you should ever have to worry about browser support issues. Original IE6 is the  exception, and like I said, it is very rare to find such a version of this browser out in the wild today. IE5 and earlier, as well as Opera 8 and earlier have no support for XSLT, but both of those have been deprecated by their creators.

W3 Schools has a good rundown on XSLT Browser support.

SEO implications

The impact of the XML/XSLT system on search engine rankings hasn’t been very well researched. Google seems to be able to process XML/XSLT pages just fine. They see the rendered content in their index and will display results based on that content.

Honestly, I can’t say for sure if this system will impact your search engine rankings in a positive or negative way. I’ll do some experimentation the next time I get the chance.

Implementation

If you already work with XML then diving into XSLT shouldn’t be that hard at all. Authoring XSLTs is notably more technical than simple HTML, but if you’re building a web application that produces XML then you must already have a good amount of technical prowess.

There are plenty of good tutorials for XSLT out there, a quick google search will give you all of the resources you will ever need to become an XSLT master. But I will provide one example XML with and XSLT to show you what it looks like.

The XML

Any XML document that is valid can be rendered with an XSLT. The only item that you will need to add to the XML document is a stylesheet declaration pointing to the XSLT file (or files) that it should use for use rendering.

Immediately after the XML declaration you will add a line of code that looks like this:

<?xml-stylesheet type="text/xsl" href="/path/to/your/xslt_file.xsl"?>

Let’s use the following XML data for this example, a search result for the string “XSLT”:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="layout.xsl"?>
<searchdata>
	<query>
		<search>XSLT</search>
	</query>
	<results>
		<class id="12" name="XSLT 101">
			<datetime>Feb 1, 2010 8:00pm PST</datetime>
			<description>A basic introduction to XSLT.</description>
			<teacher>Steven Benner</teacher>
		</class>
		<class id="18" name="Advanced XSLT">
			<datetime>Feb 2, 2010 8:00pm PST</datetime>
			<description>Advanced XSLT techniques and concepts.</description>
			<teacher>Steven Benner</teacher>
		</class>
		<class id="35" name="XSLT History">
			<datetime>Feb 1, 2010 2:00pm PST</datetime>
			<description>The history of XSLT.</description>
			<teacher>Steven Benner</teacher>
		</class>
	</results>
</searchdata>

The XSLT

There is a whole language and syntax that powers XSLT, I wont bother trying to write a full guide here. I just want to provide you with a basic example to show you how it works.

One important item to note is that XSLT selectors use XPath statements to target data. XPath, or XML Path statements treat XML data like a directory structure. Node values are targeted like a directory (e.g. parentNode/childNode), attributes are selected using an “at” sign (e.g. parentNote/@id).

This is what the XSLT for rendering it as an XHTML document would look like.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

	<!-- set output mode as html -->
	<xsl:output method="html"/>

	<!-- template that matches the root node -->
	<xsl:template match="searchdata">
		<html>
		<head>
			<title>Search Results For <xsl:value-of select="query/search" /></title>
		</head>
		<body>
			<h1>Search results for <xsl:value-of select="query/search" /></h1>

			<!-- results table -->
			<table border="1" cellpadding="5">
				<tr>
					<th>Class ID</th>
					<th>Name</th>
					<th>Teacher</th>
					<th>Description</th>
					<th>Date &amp; Time</th>
				</tr>
				<!-- run the template that renders the classes in table rows -->
				<xsl:apply-templates select="results/class" />
			</table>
		</body>
		</html>
	</xsl:template>

	<!-- template that matches classes -->
	<xsl:template match="class">
		<tr>
			<td><xsl:value-of select="@id" /></td>
			<td><xsl:value-of select="@name" /></td>
			<td><xsl:value-of select="teacher" /></td>
			<td><xsl:value-of select="description" /></td>
			<td><xsl:value-of select="datetime" /></td>
		</tr>
	</xsl:template>

</xsl:stylesheet>

This would render the following view in your browser:

Don’t believe me? Take a look at this live demo.

Alternative implementation

You can use XSLT on the server side just as easily as in the browser. If you simply cannot publish an XSLT for the web you can still use this technology as a template engine. You can build a separate presentation layer that interacts with your XML web service then run the transforms on the server side. Users will never see the raw XML.

Be warned however, XSLT is not the fastest template engine ever made. You will lose the speed benefits of publishing the XML/XSLT directly to the browser. For pure speed, a properly optimized PHP or .NET web application will out-perform it.

In .NET you have the XslCompiledTransform class, and in PHP you have the XSL extension.

Conclusion

The example I provided above is just the most basic functionality XSLT has to offer. I hope you can at least get an idea powerful this technique is and how much time it can save you on your next (or current) web application.

There is so much value in separating your data layer and presentation layer. Maybe XSLT is the solution to all of your problems, maybe XSLT is completely useless to you. Either way, it is another valuable tool in your toolbox. Remember it is there and perhaps you’ll find that you couldn’t have lived without it.

Related articles

• EXSLT set:distinct in MSXML for Internet Explorer
• Custom link click tracking using Omniture
• Friendly URLs in an ASP.NET app
• External templates for the DataView control: Microsoft Ajax Library 4.0
• Reporting of unhandled exceptions in your distributable .NET desktop application

This is a very powerful and very maintainable technique. Portable template files are a great example of the Don’t Repeat Yourself (DRY) principal and are a good idea for any template that will see reuse.

The new DataView control in the latest beta of the Microsoft Ajax Library version 4.0 (aka the ASP.NET AJAX Library) has a fine template engine built into it. Unfortunately, those templates must be embedded in the page markup. If it’s your project then you can simply use an ascx User Control, or a ContentPlaceHolder or an Html.RenderPartial, but what if you need to be able to use the template on a static file, or a clients site, or even in another framework? You can’t have portable template files that you can just call anywhere. Well, you can, but you have to use a workaround technique.

This is one technique that I came up with for importing a template file into a page. This lets me have one (or a selection of) template files that I can use everywhere for a portable JavaScript widget. It has no dependencies other than the Microsoft Ajax Library.

You can save your template as an html or xml file in your project and then, using an AJAX connection, download the template and insert it into the page. Once the template has been inserted into the page you can create the DataView control and generate the widget.

First off create the JavaScript file, in this case MyWidget.js:

var displayElement;

function WidgetInit() {
	displayElement = $get('MyWidget'); // div that we will insert the template into

	// create a new web request and pull Template.html
	var wRequest = new Sys.Net.WebRequest();
	wRequest.set_url('/Template.html');
	wRequest.set_httpVerb("GET");
	wRequest.set_userContext("user's context");
	wRequest.add_completed(WidgetWebRequestCompleted);
	wRequest.invoke();
}

function WidgetWebRequestCompleted(executor, eventArgs) {
	if (executor.get_responseAvailable()) {
		// insert the markup from Template.html into the display div
		displayElement.innerHTML += executor.get_responseData();
		// create the DataView using the inserted template
		$create(Sys.UI.DataView, { data: MyWidgetData }, null, null, $get("MyWidgetTemplate"));
	}
}

Next we’ll create Template.html, which contains our template:

<table id="MyWidgetTemplate" class="sys-template" border="1">
	<tr>
		<td>{{Name}}</td>
		<td>{{WebSite}}</td>
	</tr>
</table>

And finally bring it all together in the page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

	<head>
		<title>Microsoft Ajax DataView External Template Demo</title>
		<style type="text/css">
			/* make the template invisible until the work is done */
			.sys-template {display:none}
		</style>
		<script src="scripts/MicrosoftAjax.js" type="text/javascript"></script>
		<script src="scripts/MicrosoftAjaxTemplates.js" type="text/javascript"></script>
		<script src="scripts/MyWidget.js" type="text/javascript"></script>
		<script type="text/javascript">
			// this should come from a javascript include tag, but for the
			// sake of example, im embedding it here for you
			var MyWidgetData = [
				{ Name: "Steven Benner", WebSite: "http://stevenbenner.com/" },
				{ Name: "Bill Gates", WebSite: "http://www.gatesfoundation.org/" },
				{ Name: "Stephen Hawking", WebSite: "http://www.hawking.org.uk/" }
			];

			function pageLoad() {
				WidgetInit();
			}
		</script>
	</head>

	<body>

		<h1>Microsoft Ajax DataView External Template Demo</h1>

		<!--
			The MyWidget div is the target where the template will be
			inserted, and the widget content generated.
		-->
		<div id="MyWidget"></div>

	</body>

</html>

This is kind of a hacky solution, but it works. Often, when I want to use templates, I want to use external templates. Simple flat files that I can change, cache and version. After all, half the point of templates is having the ability to have a selection of different templates.

Related articles

• Custom link click tracking using Omniture
• Friendly URLs in an ASP.NET app
• Excessive JavaScript and AJAX: bad practice & broken pages
• Reporting of unhandled exceptions in your distributable .NET desktop application
• JavaScript regex trick: Parse a query string into an object