• Pro JavaScript Techniques
• Pro JavaScript Design Patterns
• Pro JavaScript RIA Techniques
• Object Oriented JavaScript
• JavaScript: The Good Parts
• High Performance Websites
• Even Faster Websites
• High Performance JavaScript

Pro JavaScript Techniques

This is one of the first proper books on the subject of JavaScript I ever read (the very first book on JavaScript I read I actually still own! I keep it as a reminder of where I began and I really chuckle as I flick through its pages and see the seriously shite advice it recommends as ‘best practices’. The book was “Sams Teach Yourself JavaScript in 24hrs” published back in 2001 – a horrid book that I do NOT recommend!).

But back to Pro JavaScript Techniques… I found a lot of errors in the book (in a few places there was code that just simply didn’t work and when I went online and to forums looking for answers – as the errata for the book wasn’t any help – I found a whole lot of people hating on the author John Resig http://ejohn.org/ saying it wasn’t surprising for me to find code he had written didn’t work).

Now this probably doesn’t seem like much of a recommendation, but in fact I still look back at Pro JavaScript Techniques and I can see it really opened my eyes to a lot of cross browser inconsistencies that I never would have ever dreamed possible, and although there were a few places where the scripts appeared to be broken, there were still lots of good code examples that successfully worked around the painful cross browser inconsistencies/quirks discussed in the book.

Pro JavaScript Techniques was published back in 2006 (around the time of jQuery’s initial release) so I know there was a lot that the author had learned about the language since that time through working on jQuery and so this book could probably do with an updated edition, but I still recommend it in its current form none the less.

Pro JavaScript Design Patterns

This is a very intense reference on JavaScript Design Patterns and might be a little too much for people new to JavaScript, but I think users of all skill levels will get a lot of mileage from it. I personally learnt a great deal about object oriented programming (OOP) from this book and for the OOP chapter alone I recommend it.

The design patterns are all very well explained with good working examples which you can use to help get your head around how you would use the patterns in the real world (one of my pet peeves are technical books that have weak ‘real world examples’ that are so basic that you would never consider them ‘real world’ – but all code examples are very detailed and really do a great job of properly representing the power of the patterns they are teaching).

The book then progresses into the subject of inheritance within JavaScript, both classical and prototypal, and explains the pros and cons to both varieties. It shows you how to implement Interfaces, discusses encapsulation and information hiding through private members as well as the benefits and drawbacks of these techniques and then moves on through to the design patterns themselves.

What I liked about the book (especially the opening chapters on Object-Oriented Programming) is that they show you a basic ‘bare bones’ solution, the author(s) then explain the limitations of that particular solution and move on to a more advanced option. This next solution is also flawed and so they again discuss the possible limitations, and then finally they move on and explain a complete solution that incorporates all required functionality and features while extending the example to work around the previous limitations discussed. Thus leaving you with a fully working example where you now have a solid understanding of the design pattern and the code that implements it.

Pro JavaScript RIA Techniques

This book seemed to be remarkably up to date when I bought it, including HTML5 features, cutting edge AJAX as well as SVG/Canvas implementations along with great information on how to improve your UI’s ‘perceived’ responsiveness.

It discusses everything from setting up a development environment to coding style guidelines and object-oriented JavaScript, to actually building your own JavaScript library (including things like advanced event and ajax management) and helping you understand the problems with performance critical applications and how to avoid common pitfalls. It also discusses typography and associated libraries and how to use them, and the same for multimedia playback and offline storage (all explained and included in the ‘build your own JavaScript library’ code) and finally it covers accessiblity in ajax applications.

An absolutely brilliant book on current web development trends and technologies.

Object Oriented JavaScript

I haven’t read David Flanagan’s world renowned book “JavaScript: The Definitive Guide” so I can’t say if this book is better, although from flicking through “The Definitive Guide” I know this book wont be any where near as thorough as it isn’t supposed to be a complete reference guide but more an up to date book on how to learn JavaScript in the modern environment and take advantage of lessons learned over the past few years since JavaScript has seen such a resurgence in popularity.

I found this an enjoyable book to read and a good ‘general’ reference for most issues I run into. If you’re learning JavaScript for the first time then this is the book I suggest you read.

JavaScript: The Good Parts

This book ideally should be read by anyone who already has a good understanding of JavaScript and uses it in their daily lives. It will not teach you JavaScript and will fundamentally be useless to anyone wanting to learn JavaScript and will only explain why the author Douglas Crockford http://javascript.crockford.com/ (who is a celebrated JavaScript guru) thinks certain aspects of the language are dangerous, confusing and in some cases just plain wrong.

Now it would seem that over the years developers have come to not take everything Crockford says as gospel (which is definitely a healthy way to go) but I do feel this is a great book to have in your collection and although there may be one or two areas for disagreement, on the whole I think he has put in place valid arguments and a solid dissection of the JavaScript language.

High Performance Websites

I love this book and if you need to understand how and why your site is running slow (or better still, why it doesn’t run as fast as other websites) then this is the book to read.

It starts off explaining about HTTP and content-headers, compression, expires and the purpose of Keep-Alive and in general how that whole aspect of a web application works. This is important because if you don’t understand the core concepts of how the web works then how can you begin to understand where to improve your code. It’s imperative to understand these concepts to help your application performance.

For me, at the time when I first read this book (back in 2007) one of the most important bits of information in this book came from the chapter on how JavaScript files block parallel downloads and solutions to work around that critical issue (something which is now almost common practice among front-end engineers).

It also covers topics such as caching Ajax requests, how best to handle CSS and avoiding CSS expressions, reducing DNS lookups, minifying JavaScript, avoiding redirects, configuring ETags (and how to remove them as they can cause hell with proxy servers) and finishes up with the deconstruction of the top 10 sites on the internet to help you understand what aspects of performance they are missing/neglecting.

Even Faster Websites

This is the follow up to the previous book “High Performance Website” and actually covers more JavaScript related issues such as Ajax performance, how to create responsive web applications such as measuring latency and threading (Web Workers, Google Gears, JavaScript Timers and Virtual Memory).

It also discusses flushing the content of the page early and in stages so as to improve perceived performance. It goes into further detail about how to stop JavaScript from blocking downloads and loading them in parallel with other JavaScript files and coupling asynchronous scripts. It briefly goes into writing efficient JavaScript such as managing scope, efficient data access, string optimisations and how to avoid the dreaded long running script error.

It also covers subjects such as advanced Ajax (in the form of Comet http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications), going beyond GZIP’ing, optimising images, using domain sharding to improve parallel downloading in certain browsers and simplifying CSS selectors.

All in all a very thorough book on performance issues.

High Performance JavaScript

This book covers a lot of the JavaScript topics found in “High Performance Website” and “Even Faster Websites” but includes a whole lot more on top of that for the hardcode JavaScript ninjas. And regardless, it’s actually great to have all this information under one title rather than spread across two separate books.

The context of the book was to take the reader through the complete web development life-cycle, from start to finish, so some of the subjects it looks into are the loading and executing and JavaScript and how to avoid blocking parallel downloads. It moves onto data access and scope management, DOM scripting, paints and reflows, event delegation, algorithms and flow control, strings and regular expressions, responsive user interfaces, ajax performance guidelines and programming best practices and then moves onto the deployment of your application and the testing and debugging with various tools.

To make this book even better though is that its chapters are written by a who’s who of the JavaScript elite such as… (note: the below list is taken from main author Nicholas C. Zakas website)

• Ross Harmes, co-author of Pro JavaScript Design Patterns and front-end engineer for Flickr. Ross writes about Ajax performance with an eye on squeezing out the fastest client-server messaging possible.
• Julien Lecomte, creator of the YUI Compressor and front-end engineer on Yahoo! Search. Julien describes effectively deploying your JavaScript with performance in mind.
• Steven Levithan, co-author of the Regular Expression Cookbook and guru on all things related to strings and regular expressions. Steven explains the ins and outs of string and regular expression performance in JavaScript in a way that I believe has never been done before.
• Matt Sweeney, YUI 3 architect. Matt focuses on currently available tools for measuring JavaScript performance.
• Stoyan Stefanov, author of Object-Oriented JavaScript and front-end engineer on Yahoo! Search. Stoyan investigates the performance of the DOM and how reflows and repaints affect JavaScript’s perceived performance. This chapter, to me, will be the definitive print resource for reflow information.

Conclusion

So there you have it, that’s my run down of the current list of web development and JavaScript related books I think you should own.

Feel free to share your thoughts.

1. Jan Goyvaerts (www.regexguru.com)
2. Steven Levithan (blog.stevenlevithan.com)

…(both co-authors of the Regular Expressions Cookbook) seem to be in disagreement with each other as to how Internet Explorer implements this.

According to Steven, IE’s implementation is a bug (http://blog.stevenlevithan.com/archives/exec-bugs). In Jan’s mind, IE actually did what was the right thing to do and changed the feature to work similarly to how the other RegEx methods work (although, as usual, IE isn’t following the standard as set out by the ECMAScript specification – http://www.regexguru.com/2008/04/watch-out-for-zero-length-matches/).

I personally am in agreement with Jan in that I think how IE implemented the lastIndex property is the best way of avoiding a rare (but still possible) occurrence of an infinite loop with browsers that don’t increment the lastIndex value. Although! I fully understand where Steven is coming from with regards to poor code design as lastIndex is used for two separate purposes within ECMAScript and so by IE fixing the issue with lastIndex not being properly incremented when finding a zero-width match it in fact could end up causing more confusion when used along with the RegEx test method (again read Steven’s explanation here: http://blog.stevenlevithan.com/archives/exec-bugs#comment-17444 for more details).

The lastIndex property has a few purposes in JavaScript such as:

• Specifying where the string search should begin (you would need the global modifier flag /g set for this bug to be an issue)
• Tracking the position of where the next search should start
• Indicating where the last match ended

But if for example your regex is able to succeed with a zero-width match (such as ^) and the browser doesn’t increment the lastIndex value, then the browser is going to force itself into an infinite loop – which I think is a bug.

It works a bit like the following (the original code example came from Steven’s site but I’ve changed it to suit my own needs and added in my own comments to hopefully explain sufficiently what’s happening)…

var regex = /^/gm,
    subject = "A\nB\nC",
    match,
    endPositions = [];
 
while (match = regex.exec(subject)) {
    /*
    As each match is a 'zero-width' match, an infinite loop occurs.
    i.e. the lastIndex value for each match is the same as the match index value
 
    The reason we have an infinite loop happening is because each time .exec() is run it will run from the same starting position.
    e.g. a match is found at position 0, so the lastIndex is set to 0
 
    So when the next match is attempted the regex starts from the lastIndex position of 0, and again a match is found at 0 (ad infinitum)
 
    This is as per the official ECMAScript standard
    Only IE is unaffected as it doesn't follow the standard, but for once that's a good thing!
    */
 
    // So to avoid an infinite loop...
    if (regex.lastIndex === match.index) {
        // Let's see where the infinite loops would occur
        alert("Increment lastIndex: " + regex.lastIndex); // 0, 2, 4
 
        // Avoid an infinite loop by incrementing the lastIndex value by 1
        // This is as per most other regex flavours and is also how other JavaScript methods behave? 
        // Again suggesting that the .exec() method was mistakenly defined as working the way it does.
        regex.lastIndex++;
    }
 
    endPositions.push(regex.lastIndex);
}
 
// Show each character where a match was found
for (var i=0, len=endPositions.length; i<len; i++) {
    alert("Match was found at character: " + subject.charAt(endPositions[i]-1)); // A (position=0), B (position=2), C (position=4)
}
 
// Display lastIndex value for each match
// Notice each value is 1 position ahead of where the match was found
// This is to stop browsers (such as Firefox) getting stuck in an infinite loop when the first match is a zero-width match
alert("lastIndex values after being incremented: " + endPositions);

You can see a working example on jsFiddle here: http://www.jsfiddle.net/integralist/N2xSb/.

It’s a bit of a sticky issue and one that you shouldn’t see too much of really but is definitely worth being aware of so you know how to work around it if need be.

Feel free to share your thoughts.

This solution is an updated version. The previous version was recklessly using capture groups when really they should have been using non-capturing groups (as the brackets in the following solution are solely for applying quantifiers and optional items). The reason you should use capturing groups sparingly is to do with performance and saving the regex engine from having to remember content within the capturing groups.

The Regular Expression checks for things like whether the URL is an SSL protected URL and uses a negative look ahead assertion to make sure that it doesn’t incorrectly match URL’s that *appear* to be external (e.g. they start with a http) but in fact actually are links to the current website URL (this happens a lot with Content Management Systems where a user will copy and paste the full URL to one of their own pages).

The Regex Solution

^http(?:s)?:\/\/(?!(?:www.)?integralist)

Example Code

/**
 * The Integralist global namespace object.
 *
 * @class Integralist
 * @singleton
 * @static
 */
function Integralist() {
	// Constructor
}
 
/**
 * Augment the Integralist class so it includes a method
 * which finds all <a> elements that link to an external website
 * and sets them to open in a popup window
 */
Integralist.prototype.external = function() {
	var that = this; // Required to keep scope within the following Closure
	this.settings = 'location=yes,resizable=yes,width=' + screen.availWidth + ',height=' + screen.availHeight + ',scrollbars=1,left=0,top=0';
	this.popup = function(node) {
		var url = node.href;
		return function() {
			window.open(url, 'external' , that.settings);
			return false;
		};
	};
 
	var a = document.getElementsByTagName('a'), // Private variable to store HTMLCollection of all </a><a> elements
		 len = a.length, // Store array length in variable
		 pattern = /^http(?:s)?:\/\/(?!(?:www.)?integralist)/; // RegExp pattern to match any external URL's but not the current website
 
	// Loop through the array checking for any A elements that link to an external URL
	while (len--) {
		var element = a[len].getAttribute('href');
		if (pattern.test(element)) {
			a[len].onclick = this.popup(a[len]);
		}
	}
};
 
// Create a singleton of the Integralist Class
var Integralist = new Integralist();
 
// Trigger 'external' method
window.onload = Integralist.external;

Update 1

Tweaked the regex again to make it simpler. Decided using a character class for just a single dot character was pointless, might as well just escape the dot. Also got rid of the non-capturing group around the s in https and just used an optional token ? on its own as again it was pointless wrapping a single character in a non-capturing group.

^https?:\/\/(?!(?:www\.)?integralist)

Update 2

I’ve ended up tweaking the regex again to take into account files that don’t start with http but should still open in a pop-up window. For example if a website links to a self hosted PDF file it might store it in the following directory path Assets/Documents/MyFile.pdf.

First thing I did was add a case-insensitive modifier flag (which I simply forgot last time).

Now to work around the issue of linking to internal documents that should open in a pop-up I place a non-capturing group after the opening anchor ^. Within this group it has a character class that allows a period . and a forward slash / and uses a quantifier + so it matches 1 or more times. I then make the whole group optional.

Next, we take the original regex and wrap it in a non-capturing group and place it after the preceding code. Inside the non-capturing group, at the start we add the name of the directory we are looking for (in this case I just need to look for the word “Assets” and I know it’s going to link to a document and not a HTML file). I then put in the alternator meta-character so it will look for “Assets” and if it can’t find it the regex engine will backtrack to this point and try the rest of the regex which we’ve already discussed.

So the final regex looks like this…

^(?:[.\/]+)?(?:Assets|https?:\/\/(?!(?:www\.)?integralist))

I recently had a job where a <h1> tag needed to be split onto two or more lines. The reason for it to be split up onto multiple lines was to make it fit the creative our designers had come up with (which was an old skool style 80′s retro looking banner – not the easiest thing in the world to pull off basically).

The code for the header initially looked like this…

<h1>
	one two<br />
	three<br />
	four</h1>

But the next issue I came across was that to be able to implement this crazy design and have it be cross-browser compatible I needed to force in a   (non-breaking space) before and after the line breaks, AND wrap the whole thing in a <div> such as this…

<div class="h1block">
	<h1>
		one two&nbsp;<br />&nbsp;
		three&nbsp;<br />&nbsp;
		four</h1>
</div>

But the biggest issue was that the site and all its text was controlled by a Content Management System (CMS), so there was no way I could control this sort of strict styling.

Here is where Regular Expressions came to the rescue.

Now, to my mistake I tried to implement this using one Regex. I almost got it but then hit a brick wall…

Original Regex

(<h1>)(?:([^<]*?)(<br />))*?([^<]*?)(</h1>)

Original Replacement Text

<div class="h1block">$1$2&nbsp;$3&nbsp;$4$5</div>

But the problem I had was that the replacement only remembers the 2nd before last line “three”, and not “one two”.

Regex Guru “Jan Goyvaerts” then pointed me in the right direction and suggested that I not over complicate things and instead split my single monolithic regex into two.

Although the following solution is actually written in JavaScript I eventually got our server-side developer to implement a similar solution using PHP’s preg_replace (the Regex itself didn’t need to change, just the syntax sugar around it).

var subject = "<h1> \
    one two<br /> \
    three<br /> \
    four \
    </h1>";
 
var content,
    pattern = /<h1>([\S\s]*)<\/h1>/,
    match = pattern.exec(subject);
 
if (match != null) {
    content= match[1];
 
    pattern = /<br\s*\/?>/g;
    final = content.replace(pattern, "&nbsp;$&&nbsp;"); // $& is a reference to the matched content
 
    document.write('<div class="h1block"><h1>' + final + '</h1></div>');
}

Working Example

You can also go direct to the example on jsFiddle: http://jsfiddle.net/Jrhdb/

Final Regex Solution(s)

Here we match a literal <h1> followed by any character zero or more times, which itself is wrapped in a ‘capture group’ so we can refer back to the content of the group later on, followed lastly by a literal </h1>.

<h1>([\S\s]*)<\/h1>

Then, in the above JavaScript example we take the content within the capture group and look for any
tags, as per the regex which follows…

<br\s*\/?>

…we then use JavaScript’s replace() method to insert the non-breaking spaces (&nbsp).

And finally we use simple string concatenation to wrap the appropriate div around the entire match.

Some Additional Regex Text Replacement Surprises

Through this process I actually learned about JavaScript’s special tokens for reinserting the overall regex match which is $&. There is also $‘ which inserts the portion of string that precedes the matched substring, and there is $’ which inserts the portion of string that follows the matched substring.

None of these three special tokens I knew about until now! I only ever knew about numbered back references such as $1, $2, $3... and I’m surprised not to see it in more JavaScript books (up till now I’ve only seen $& mentioned in the excellent book “Regular Expressions Cookbook”, and have been told all three are briefly mentioned in the reference section of “JavaScript: The Definitive Guide”?).

Either way, useful knowledge to have.

Interfaces are useful for making sure developers use the correct implementation of an API.

In JavaScript there are no true ‘classic’ Object-Oriented features, but through clever usage of the language you can emulate an Interface for use with a JavaScript API.

First thing you want to do is include the following JavaScript file (Interface.js) into your HTML:

/*
 * Constructor that creates a new Interface object for checking a function implements the required methods.
 * @param objectName | String | the instance name of the Interface
 * @param methods | Array | methods that should be implemented by the relevant function
 */
var Interface = function (objectName, methods) {
	// Check that the right amount of arguments are provided
	if (arguments.length != 2) {
		throw new Error ("Interface constructor called with " + arguments.length + "arguments, but expected exactly 2.");
	}
 
	// Create the public properties
	this.name = objectName;
	this.methods = [];
 
	// Loop through provided arguments and add them to the 'methods' array
	for (var i = 0, len = methods.length; i < len; i++) {
		// Check the method name provided is written as a String
		if (typeof methods[i] !== 'string') {
			throw new Error ("Interface constructor expects method names to be " + "passed in as a string.");
		}
		// If all is as required then add the provided method name to the method array
		this.methods.push(methods[i]);
	}
};
 
/*
 * Adds a static method to the 'Interface' constructor
 * @param object | Object Literal | an object literal containing methods that should be implemented
 */
Interface.ensureImplements = function (object) {
	// Check that the right amount of arguments are provided
	if (arguments.length < 2) {
		throw new Error ("Interface.ensureImplements was called with " + arguments.length + "arguments, but expected at least 2.");
	}
 
	// Loop through provided arguments (notice the loop starts at the second argument)
	// We start with the second argument on purpose so we miss the data object (whose methods we are checking exist)
	for (var i = 1, len = arguments.length; i < len; i++) {
		// Check the object provided as an argument is an instance of the 'Interface' class
		var interface = arguments[i];
		if (interface.constructor !== Interface) {
			throw new Error ("Interface.ensureImplements expects the second argument to be an instance of the 'Interface' constructor.");
		}
 
		// Otherwise if the provided argument IS an instance of the Interface class then
		// loop through provided arguments (object) and check they implement the required methods
		for (var j = 0, methodsLen = interface.methods.length; j < methodsLen; j++) {
			var method = interface.methods[j];
 
			// Check method name exists and that it is a function (e.g. test[getTheDate]) 
			// if false is returned from either check then throw an error
			if (!object[method] || typeof object[method] !== 'function') {
				throw new Error ("This Class does not implement the '" + interface.name + "' interface correctly. The method '" + method + "' was not found.");
			}
		}
	}
};

Next, in the HTML file we have an inline script that creates a new Interface instance and then passes it the methods we are expecting. The user of the API would need to implement an object literal of all the methods the interface requires (note the following code could be in a separate SCRIPT file as long as it is run after the above script):

// We pass into the Interface the name of the current Interface instance, 
// followed by an Array of the methods we are expecting to find
var test = new Interface('test', ['details', 'age']);
 
var properties = {
	name: "Mark McDonnell",
	actions: {
		details: function() {
			return "I am " + this.age() + " years old.";
		},
		age: (function(birthdate) {
			var dob = new Date(birthdate),
				today = new Date(),
				ms = today.valueOf() - dob.valueOf(),
				minutes = ms / 1000 / 60,
				hours = minutes / 60,
				days = hours / 24,
				years = days / 365,
				age = Math.floor(years)
			return function() {
				return age;
			};
		})("1981 08 30")
	}
};
 
// Create a Person constructor that will implement the above properties/methods
function Person(config) {
	// Pass in the methods we are expecting, 
	// followed by the name of the Interface instance that we're checking against
	Interface.ensureImplements(config.actions, test);
 
	this.name = config.name;
	this.methods = config.actions;
}
 
// Create a new instance of the Person constructor...
var me = new Person(properties);
 
// ...and make sure the methods are working
alert(me.methods.age());
alert(me.method.details());

For example, you’ll normally find a lot of form validation is done using Regular Expressions (see: http://codecanyon.net/item/validate/54689).

Regular Expressions are available in one form or another in most programming languages. One minor point to make here is that although most programming languages include Regular Expressions, they can differ in implementation from language to language. So you may find the particular Regular Expression feature you want to use is not supported in your language of choice.

JavaScript for example implements the Perl 5 syntax (and as such doesn’t support certain features such as ‘look-behind’ constructs).

When writing a Regular Expression you will start with the string you want to match a pattern against. You’ll write your Regular Expression ‘pattern’ and will then assign one (or more) ‘modifiers’ to the Regular Expression object which will effect how the pattern is run.

For example if you wanted to search a string for the word “JavaScript” your pattern would be /JavaScript/, but if your string had that word only in lowercase (i.e. “I love javascript”) then the pattern match would fail. So you would assign a “case insensitive” modifier to let the Regular Expression engine know that it is free to find matches as either “JavaScript” or “javascript” or even “JAVASCRIPT”.

There are three types of modifiers:

• i, – “ignore case” – the case (uppercase/lowercase) of all letters within the string will be ignored during testing.
• g, – “global search” – the search is carried out across the entire string, regardless of whether a match has already been found.
• m, – “multiline search” – the regular expression will match over multiple lines.

In JavaScript there are essentially three main methods for handling Regular Expressions:

1. String.match (returns an Array of matches)
2. RegExp.exec (returns an Array of matches)
3. RegExp.test (returns a Boolean true/false)

The only difference between String.match and RegExp.exec is that the latter will return capture groups plus the first match (if a global modifier has been used), where as the former won’t return any capture groups only the full matches. Note: a capture group is when you wrap a certain set of characters in parenthesis, any text in () will then be remembered after the Regular Expression has run and can be replaced or moved (see below for an example of this).

The RegExp.test method is probably the most useful as far as validation testing is concerned as the majority of the time you just want to check if a specific value is present.

I’ve included some extremely basic examples below as a way to gently introduce newcomers to the terminology of Regular Expressions. A great tool for testing Regular Expressions can be found here: http://gskinner.com/RegExr/ (I highly recommend you try it).

In my examples I’ve used the String.match method of matching patterns and I’ve also used the ‘regexp literal’ form of creating Regular Expression (e.g. /my-regexp-pattern/) but, there is also the RegExp() constructor which allows you to create Regular Expression objects.

The only benefit of using the RegExp constructor is if you need to search for patterns dynamically (i.e. with unknown data. For example, such as at runtime when the user specifies a word they want to search for).

Regular Expression Basic Examples…

NOTE: Two of the examples use what is called a ‘look-ahead’ construct (I demonstrate a positive and negative variation of the look-ahead) and although Regular Expressions do have a ‘look-behind’ construct, the current version of JavaScript doesn’t implement it. There are ways to mimic it but that is outside the scope of this article so I’ll refer you to here: http://blog.stevenlevithan.com/archives/mimic-lookbehind-javascript

<script>
	var string = "Here is some text about JavaScript (also known as JScript). It contains multiple references to jscript/javascript because this article is all about JAVASCRIPT.";
 
	// returns: [JavaScript]
	// Although there are multiple references to the word "javascript" I've not included the "global" modifier so it has only returned the first match
	console.log(string.match(/javascript/i));
 
	// returns: [JavaScript,javascript,JAVASCRIPT]
	console.log(string.match(/javascript/ig));
 
	// returns: ["Java", "java", "JAVA"]
	console.log(string.match(/java/ig));
 
	// returns: [a,J,a,v,a,a,a,J,a,j,j,a,v,a,a,a,a,a,J,A,V,A]
	// Match any single character in the set (e.g. /defen[cs]e/ would matche either defense or defence).
	console.log(string.match(/[java]/ig));
 
	// returns: [e,r,e,i,s,s,o,m,e,t,e,x,t,a,b,o,u,t,a,v,a,c,r,i,p,t,a,l,s,o,k,n,o,w,n,a,s,c,r,i,p,t,t,c,o,n,t,a,i,n,s,m,u,l,t,i,p,l,e,r,e,f,e,r,e,n,c,e,s,t,o,j,s,c,r,i,p,t,j,a,v,a,s,c,r,i,p,t,b,e,c,a,u,s,e,t,h,i,s,a,r,t,i,c,l,e,i,s,a,l,l,a,b,o,u,t] 
	// Match any single character in the set (e.g. /defen[cs]e/ would matche either defense or defence).
	// Notice the capital letters are missing from the result set.
	console.log(string.match(/[a-z]/g));
 
	// returns: [H, , , , , ,J,S, ,(, , , ,J,S,),., ,I, , , , , ,/, , , , , , , ,J,A,V,A,S,C,R,I,P,T,.] 
	// Match any single character that is not in the set.
	// Matches anything that isn't a capital (includes spaces inbetween words)
	console.log(string.match(/[^a-z]/g));
 
	// returns: [J,J,j,j,J]
	// Alternation. Equivalent of "or". Matches the full expression before or after the |.
	console.log(string.match(/J|j/g));
 
	// returns: [J,j,J] 
	// Positive lookahead. Matches a group after your main expression without including it in the result.
	// Matches j that have "ava" following them (so jscript or JScript don't match)
	console.log(string.match(/J(?=ava)/ig));
 
	// returns: [J,j] 
	// Negative lookahead. Specifies a group that can not match after your main expression (ie. if it matches, the result is discarded).
	// Matches j that HASN'T got "ava" following them (so jscript & JScript return a match)
	console.log(string.match(/J(?!ava)/ig));
 
	// returns: [ , , , , , , , , , , , , , , , , , , , , , ]
	// \s matches any whitespace character (spaces, tabs, line breaks).
	console.log(string.match(/\s/g));
 
	// returns: [JavaScript,javascript,JAVASCRIPT] 
	// \b matches a word boundary position such as whitespace or the beginning or end of the string.
	console.log(string.match(/J.{6}ipt\b/ig));
 
	// returns: [JavaScript,javascript,JAVASCRIPT]
	// {} means to match a pattern a specified number of times (in this case any character 6 times after "J" and ending in "ipt")
	console.log(string.match(/J.{6}ipt/ig));
 
	// returns: "Here is some text about JJavaScript (also known as JScript). It contains multiple references to jscript/jjavaScript because this article is all about JJavaScript."
	// Groups multiple tokens together. This allows you to apply quantifiers to the full group. This creates a capturing group.
	// Notice the double "JJ" where we've captured the letter j and then replace it with itself twice.
	// If you capture more than one item then all subsequent capture groups are referenced by number incrementally (e.g. $2, $3, $4 etc.)
	console.log(string.replace(/(j)avascript/ig, '$1$1avaScript'));
</script>

In the following code example we have a ‘Person’ Class which has no methods.
We also have another Class called ‘Mixin’ which has three methods.
We will augment the ‘Person’ Class so it has access to two of the three methods within the ‘Mixin’ Class.

I’ve not put any further details as the code should be self-explanatory. Otherwise I suggest you purchase the book “Pro JavaScript Design Patterns” to help yourself understand what the code does and why.

/* Person Class */
var Person = function(settings) {
	this.name = settings.name || 'no name given';
	this.age = settings.age || 'no age given';
};
 
/* Mixin Class */
var Mixin = function(){};
Mixin.prototype = {
	doSomething1: function() {
		alert('do something 1!');
	},
	doSomething2: function() {
		alert('do something 2!');
	},
	doSomething3: function() {
		alert('do something 3!');
	}
};
 
// Function to augment an existing class with a method(s) from another class
function augment(receivingClass, givingClass) {
	// Only give certain methods
	if (arguments[2]) {
		for (var i=0, len=arguments.length; i<len; i++) {
			receivingClass.prototype[arguments[i]] = givingClass.prototype[arguments[i]];
		}
	}
	// Give all methods found
	else {
		for (methodName in givingClass.prototype) {
			// A quick check to make sure the receiving class doesn't already have a method of the same name as what's currently being processed
			if (!receivingClass.prototype[methodName]) {
				receivingClass.prototype[methodName] = givingClass.prototype[methodName];
			}
		}
	}
}
 
// Augment the Person class to have the methods 'doSomething1' and 'doSomething3'
/*
	We can also do...
		augment(Person, Mixin);
	...so the 'Person' class receives ALL methods within 'Mixin'.
*/
augment(Person, Mixin, 'doSomething1', 'doSomething3');
 
// Create a new Person
var employee = new Person({name:'John Smith', age:27});
 
// Test to make sure we have access to the relevant methods
employee.doSomething1();
employee.doSomething3();
 
// Just to prove we aren't copying all the methods from the 'Mixin' Class...
try {
	employee.doSomething2();
} catch(e) {
	alert(e.message);
}

It has also been explained to me that the particular solution I’m going to discuss here is the same technique used by the jQuery library.

I’m not going to run through how to actually write an AJAX method as that is outside the scope of this post, so feel free to use your own home baked JavaScript code, or use any one of the numerous JavaScript libraries as they all include their own variation of a cross-browser AJAX call.

With most AJAX scripts you’ll also specify a callback function which will run once the requested data has been retrieved. In my case this looks something like this…

$.Remote.load({
	url: "Test.html",
	callback: function(response)
	{
		// Do something with the response object
	}
});

Once my AJAX function has successfully retrieved the data, it runs the callback function which then processes the data and grabs the element we’re interested in.

Within the callback function we first need to create a new element and then set the elements innerHTML to the response data (which is returned as a String).

We then grab all the elements we’re interested in (for this example I’m specifically looking for a DIV element that has an ID value of “content”) and loop through them until we find the relevant node…

// Load the contents of the HTML file 'Test.html'
$.Remote.load({
	url: "Test.html",
	callback: function(response)
	{
		// Now we have the HTML as a String 
		// lets parse it into a DOM node
		// so we can then locate an element 
		// within the HTML we want to pull in
 
		// Create an empty DIV which wont be used for anything
		// other than storing the HTML response
		var tempNode = document.createElement("div");
 
		// Set the DIV's innerHTML to the HTML String we've received
		tempNode.innerHTML = response.text;
 
		// Grab a reference to all DIV's in the 'Test.html' page
		var nodes = tempNode.getElementsByTagName("div");
 
		// Loop through each DIV found...
		for (var i=0, len=nodes.length; i<len; i++) {
			// ...looking for the DIV we want
			if (nodes[i].id === "content") {
				// Insert the found element into the page
				document.body.appendChild(nodes[i])
 
				// Clean-up
				var tempNode = null;
				var nodes = null;
 
				// Break the loop now we have found the element we want
				break;
			}
		}
	}
});

Simple as that!

Obviously you could clean this up a lot and write a function that takes in as an argument the element you’re looking for as well as a class name/id and then have it return the relevant content, but for this example I’m just using my own box standard AJAX code and searching through the response data from within my callback function.

Remember also that this is just example code and is far from perfect, but hopefully it has at least clarified the process of how to grab an HTML fragment from a separate HTML page using AJAX.

The following code is an amalgamation of the work of Jesse Skinner and Byron McGregor. It keeps track of the methods passed into the addDOMLoadEvent function and supports all modern browsers such as Firefox, Chrome, Opera, Safari (higher than 525) and falls back to window.onload for those browsers that fail all the other checks.

I’ve also updated the code to take into account one particular issue I found with previous versions when using the doScroll method of targeting Internet Explorer which would sometimes return “unavailable”, as well as fixing a Firefox error when hitting the Safari targeted code.

To start with lets take a look at the HTML for my test page:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>JavaScript. onDOMLoad</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<style type="text/css">
	*
	{ font-family: Arial, Helvetica, sans-serif; }
 
	li
	{ margin:25px; }
</style>
</head>
<body>
 
	<h1>addDOMLoadEvent Demo Page</h1>
	<h2>Supports Mozilla/Opera/Chrome/Safari > 525/IE6+</h2>
 
	<ol>
		<li>JavaScript will add more LI elements once the DOM is loaded.</li>
		<li><img src="Large1.jpg" height="100" width="100"> (approx 1.5mb)</li>
		<li><img src="Large2.jpg" height="100" width="100"> (approx 1.5mb)</li>
		<li><img src="Large3.jpg" height="100" width="100"> (approx 1.5mb)</li>
	</ol>
 
	<script type="text/javascript" src="domready.js"></script>
	<script type="text/javascript" src="library.js"></script>
 
</body>
</html>

The following code adds elements to the DOM while the images continue to download:

var MYAPP = {
	init: function()
	{
		MYAPP.addListElement("Thanks, the DOM appears to be loaded!");
	},
	addFunction: (function()
	{
		// Create a closure
		// so we can keep track of
		// the number of times this method is called
		var counter = 0;
		return function()
		{
			counter++;
			MYAPP.addListElement("Some random text " + counter);
		}
	})(),
	addListElement: function(text)
	{
		var li = document.createElement("li");
		li.appendChild(document.createTextNode(text));
		var ol = document.getElementsByTagName('ol').item(0);
		ol.appendChild(li);
	}
}
 
addDOMLoadEvent(MYAPP.init);
addDOMLoadEvent(MYAPP.addFunction);
addDOMLoadEvent(MYAPP.addFunction);
addDOMLoadEvent(MYAPP.addFunction);
addDOMLoadEvent(MYAPP.addFunction);
addDOMLoadEvent(function()
{
	MYAPP.addListElement('MY FINAL METHOD CALL');
});

And now here is the final addDOMLoadEvent code:

var addDOMLoadEvent = (function()
{
	var load_events = [], // Stacks all functions sent to addDOMLoadEvent
   	 load_timer, // Used as a timer for versions of Safari older than 525 and Internet Explorer
       done, // Used to check when the DOM has completed loading
       exec, // Used to execute each function in the load_events stack
       old_onload; // Used as a fallback for older browsers that fail all other means of emulating DOMContentLoaded
 
	// The init method will be called when the DOM is loaded (or when the window.onload event is triggered).
	// It lets the application know the DOM is ready by setting 'done' to true,
	// then runs a quick clean up of the load_timer interval,
	// and then executes all the functions in the load_events stack (in the order they were added).
	var init = function()
	{
		done = true;
 
		clearInterval(load_timer);
 
		while ((exec = load_events.shift())) {
			exec();
		}
	};
 
	return function (func)
	{
		// We check to see if the DOM has already loaded.
		// If it is then just run the function that's trying to be called and stop there.
      if (done) {
			return func();
		}
 
      if (!load_events[0]) {
      	if (document.addEventListener) {
				// Standard compliant browsers (inc. Mozilla/Opera/Chrome/Safari)
				document.addEventListener("DOMContentLoaded", init, false);
			}
 
			// Internet Explorer
 
			/**
			 * For full information see comment 201
			 * http://dean.edwards.name/weblog/2006/06/again/#comment335794
			 *
			 * Summing up the IE challenge:
			 * Initialization event behaviours and order vary greatly among different pages.
			 *
			 * Dean Edwards document.write of the deferred script has given problems on some pages (causing a consistent > 60 sec delay).
			 * Dean confirmed that document.readyState is unreliable.
			 * We have seen cases where document.readyState was “complete” while document.body was still null.
			 * And other cases where document.readyState was not complete until after all images on the page were loaded.
			 *
			 * The doScroll method has been seen to succeed while document.body is still null.
			 * And as already mentioned, document.body can be non-null prior to the DOM being available.
			 *
			 * One solution that so far has tested 100% OK is to combine a test for both document.body and success of doScroll.
			 * And this is the method we use as it has so far provided perfect DOMContentLoaded emulation on all pages tested.
			 * Sometimes the doScroll is not available and IE falls back to window.onload so I've used a timer to counter this.
			 *
			 * Note that we use IE's Conditional Compilation to target IE rather than browser sniffing
			 * http://msdn.microsoft.com/en-gb/library/121hztk3(VS.85).aspx
			 */
 
			/*@cc_on @*/
			/*@if (@_win32)
				load_timer = setInterval(function()
				{
					if (document.body) {
						try {
							document.createElement('div').doScroll('left');
							clearInterval(load_timer);
							return init();
						} catch(e) {}
					}
				}, 10);
			@*/
			/*@end @*/
 
			// Safari (versions older than 525 which don't support the DOMContentLoaded event)
			// Use a try-catch statement to make sure no errors (such as Firefox generates) are displayed.
			try {
				if (navigator.userAgent.match(/AppleWebKit\/(\d+)/)[1] < 525) {
					load_timer = setInterval(function()
					{
						if (/loaded|complete/.test(document.readyState)) {
							init();
						}
					}, 10);
				}
			} catch(e) {}
 
			// For other browsers fall back to calling init() on the window.onload event.
			// But first store the original window.onload (just in case it was already set) and execute after init().
			old_onload = window.onload;
			window.onload = function()
			{
				// Calling init() within the window.onload event wont affect modern browsers.
				// The reason being the init() function has already been called.
				// So the stack of waiting functions have been cleared out already.
				init();
 
				// Run the original window.onload after init()
				// as window.onload should run after DOMContentLoaded.
				if (old_onload) {
					old_onload();
				}
 
				alert("window.onload is complete");
			};
		}
 
		// We push the requested function into the stack array,
		// which will be executed either once the DOM has loaded or the window.onload is called.
		load_events.push(func);
	}
})();

This seems to work pretty well for me.

I’m always interested to hear other peoples views on the DOMContentLoaded dilemma so if you see anything that you would change then feel free to share.

This post assumes ActionScript 3.0/Flash Player 9+ and for the purposes of this article I’ve avoided using certain best practices (such as inserting Flash content using SWFObject – click here to find out more about the SWFObject project). The reason being it helps concentrate the article on the core concepts we’re trying to get across and not get too distracted with best practices which you are probably already aware of (or should be).

But for those people who may be new to some of the ‘best practice’ concepts I mention through the course of this article, for you I have referenced external material that will help you appreciate the benefits of the best practices I mention and encourage you to adhere to them.

Now back to the article.

As I said, if you need to access your Flash/ActionScript functions via JavaScript then the easiest way to do this is with the ExternalInterface API (click here to read the Adobe documentation).

The basic premise is to use the addCallback method of the ExternalInterface API to register your Flash ActionScript functions so they become accessible to JavaScript.

An example of this is as follows…

/*
 * @param {String}, name that JavaScript uses to access ActionScript function
 * @param {Function}, the ActionScript function to be executed
 */
ExternalInterface.addCallback("myRegisteredFunctionName", displayMessage);

We’ll just imagine that you’ve written your ActionScript function displayMessage already (as it doesn’t really matter for this article what the function does), but lets say it excepts one parameter, a string, which is then used to update a text field in the Flash movie.

This would look something like…

function displayMessage(msg)
{
	// 'txtfield' is the instance name we have given the dynamic input field
	txtfield.text = msg;
}

Now the next part is to call the registered function via JavaScript.

To do this from JavaScript you need to get a reference to the Flash Player object, which can be a bit tricky as there are two basic versions that run in the browser: ActiveX and the plug-in version.

The ActiveX version runs natively in Internet Explorer, while the plug-in version is used by all other browsers.

To grab a reference to the ActiveX version you’ll need to assign the <object> tag an id attribute/value. I’ve used “InternetExplorerID” but you can call it whatever you want.

To grab a reference to the Embed version you’ll need to assign the <embed> tag a name attribute/value. I’ve used “AllOtherBrowsersID” but again you can call it whatever you want.

For example…

<!-- notice I've stripped out a lot of code for the sake of brevity -->
<object id="InternetExplorerID"...>;
	<param name="movie" value="TEST.swf">
	<embed name="AllOtherBrowsersID" src="TEST.swf"></embed>
</object>

Now we know what attributes to assign to each Flash Player version how do we actually access them from JavaScript? Guess what, our old favourite… the cross-browser dilemma is back! Internet Explorer uses window.objectID while all other browsers use window.document.embedName

Now i’ve seen some people suggest using browser-sniffing to achieve the result we’re after and although this article isn’t about best practices but trying to give you the core answers you’re looking for, I still can’t bring myself to use JavaScript code like if(navigator.appName.indexOf("Microsoft") != -1) !

So we’ll try something a little different…

window.onload = function()
{
	// Internet Explorer
	if (window.document.AllOtherBrowsersID == undefined) {
		flash = window.InternetExplorerID;
	} else {
		flash = window.document.AllOtherBrowsersID;
	}
 
	callFlashFunction();
};

The above code should require no extra explanation but just in case…

We wait until the page has finished loading and then we check whether the non-Internet Explorer way of accessing the Flash Player object is undefined (we could shrink this down further with a ternary operator but lets keep it simple for examples sake), if it is undefined then that means we’re using Internet Explorer and depending on the results we create a global variable to store the Flash Player version (I know, I know, “global variables are evil” and best practice is to avoid cluttering the global name space - see: http://yuiblog.com/blog/2006/06/01/global-domination/ for more information).

callFlashFunction does exactly what it says on the tin and calls the Flash registered function.

Now, callFlashFunction *would* normally just use the global variable “flash” followed by a dot and the name of the registered Flash function, such as…

// "flash" is a reference to the global variable we created earlier
flash.registeredFunctionName("my message from JavaScript");

…but the problem we have now is that although the above line of code works fine with Internet Explorer (e.g. when the page loads the Flash function is called successfully) we have an issue with all other browsers that call the function too early (before the Flash movie has finished loading) and thus it appears as if nothing happens for those browsers.

So to work around this issue we must use a recursive function that checks the Flash registered function and if it returns undefined then recurse (i.e. the JavaScript function calls itself) over and over until the Flash registered function is available to the browser.

The code to do this is as follows…

var callFlashFunction = function()
{
	if (flash.registeredFunctionName == undefined) {
		setTimeout(callFlashFunction, 500);
	} else {
		flash.registeredFunctionName("my message from JavaScript");
	}
};

And that is all there is to it, not to horrible I guess.

Any other perspectives? Feel free to let me know.