This can be a nightmare to deal with, as you cannot ask all users of a web site to change their browser settings.

One workaround is to use a ‘cache buster’ parameter in your GET request. Something like this:

var urlToFetch = 'whatever.php?randNum=' + new Date().getTime();

This works very well, but can have drawbacks, depending on your server setup. For example, if your application server sits behind a caching layer, you wouldn’t want the URL to be different every time for idempotent requests, as the cached version would never get used, and so your application server would get a direct hit every time.

One way around this without using to parameters is to set the ‘Cache-Control’ response header to direct the browser how to cache the response.

The ‘Cache-Control’ header can have various values, one of which is ‘no-cache’. This tells the browser that it should not cache the response, so the next time the same URL is requested, new content will always be sent (as there is no previous version in the browser’s cache).

This is how we do it using Groovy:

response.addHeader "Cache-Control", "max-age=0,no-cache,no-store"

So really, which method you use boils down to this: If you know that the cache buster will have a performance hit on your setup, then don’t use it, otherwise use whichever method you prefer.

Also, as a developer, I can highly recommend changing your IE cache settings to ‘Every visit to the page’.

We’re finding that with some of our automated testing, IE 7 still caches the odd file now and then. To get around this, we have modified our ‘Cache-Control’ header to include two non-standard properties, ‘post-check’ and ‘pre-check’, and added an ‘Expires’ header as well:

response.addHeader "Cache-Control", "max-age=0,no-cache,no-store,post-check=0,pre-check=0";
response.addHeader "Expires", "Mon, 26 Jul 1997 05:00:00 GMT"

• Speed up your Javascript part 1
• Speed up your Javascript part 2

This is an ongoing series of articles with specific Javascript examples that make sense.

There were 3 reasons, really… 1: I’ve just started a new project and don’t need most of the bloat Prototype comes with; 2: I can now make a judgement call when it comes to choosing a framework; and 3: It’s another skill on my CV )

I’ve just spent the weekend reading jQuery in Action cover-to-cover, and I can highly recommend it for intermediate or advanced developers looking to see what it offers.

The one thing I miss from Prototype however are the “bind” and “bindAsEventListener” commands which can set the context (”this”) of the callback – in my case, the instance of a class.

After a bit of searching, I found this post by Andreas Gohr. It was coderjoe’s comment that set the wheels in motion. He showed that you could rewrite this Prototype code:

initialize: function() {
	Event.observe(someEl, 'click',
		this.doSomething.bindAsEventListener(this)
	);
}

as this jQuery code:

init: function() {
	var self = this;
	$(someEl).bind('click', function(eventData) {
		self.doSomething(eventData, self);
	});
}

The bind (and related) method allows you to pass three parameters, however: the event type, some data, and a callback function. If the data parameter is omitted, the callback can be put as the second parameter.

So, we can re-write that last example using the second data parameter, removing the need to set a scoped variable:

init: function() {
	jQuery(someEl).bind('click', {thisContext:this}, function(eventData) {
		eventData.data.thisContext.doSomething(eventData);
	});
}

You basically put the page into design mode – so the content becomes editable. Enter this in the URL bar:

javascript:void(document.designMode='on');

You can also add spell checking to fields which do not have it by default (e.g. single-line input elements) by adding a “spellcheck” attribute set to “true”, e.g.:

<input type="text" size="50" spellcheck="true">

See https://developer.mozilla.org/en/Controlling_spell_checking_in_HTML_forms for more information.

Now you want to click a link within the iframe content and have that perform some action on the parent page (maybe you want to submit a form on the parent page, maybe you want to adjust the height of the iframe on the parent page). And you start getting frustrated because the browser won’t let you access all your javascript functions/properties on another domain.

Communication from an iframe that has content from a domain other than the one the iframe is contained within is a constant source of frustration – as browsers prevent this kind of activity due to built-in security policies. The solution is actually relatively painless requiring the addition of an iframe (see the following diagram).

You can see a working example of this over at Sky Movies where the iframe is resized as the content within the iframe changes. This is being controlled from within the iframe.

Why do we need to implement a solution like this in the first place?

Because whilst the main page at movies.sky.com can set the height of the iframe, it cannot get the height of the iframe content… and the iframe document can get it’s height but it can’t set the height of it’s enclosing iframe.

Using the following example pages, we can create a demonstration of this technique. Following is the source of the main page (marked as [1] in the figure above) which contains the iframe and the function that will be used to resize the iframe.

<html>
<head>
	<title>Page hosted on example.com</title>
	<script type="text/javascript">
	function resizeIframeHeight(nHeight) {
		var iframe = document.getElementById('mainIframe');
		iframe.setAttribute('height', nHeight);
	}
	</script>
</head>
 
<body>
	<h1>This page is hosted on the example.com domain</h1>
	<p>The iframe below is hosted on the example.org domain</p>
	<iframe id="mainIframe" width="400" height="200" src="http://example.org/iframedDocument.html">Iframes not supported.</iframe>
</body>
</html>

Following is the source of the iframe page (marked as [2] in the figure above) which contains the extra iframe and some javascript that allows this technique to work.

<html>
<head>
	<title>Page hosted on example.org</title>
	<script type="text/javascript">
	function updateIframeHeight() {
		var iframe = document.getElementById('hiddenIframe');
		var newHeight = parseInt(document.body.offsetHeight,10) + 10;
		iframe.src = 'http://example.com/xssEnabler.html?height=' + newHeight;
	}
	</script>
</head>
 
<body onload="updateIframeHeight()">
	<h1>This page is hosted on the example.org domain</h1>
	<p>The iframe below is hosted on the example.com domain (and be styled to be hidden)</p>
	<iframe id="hiddenIframe" width="100" height="100" src="http://example.com/xssEnabler.html">Iframes not supported.</iframe>
</body>
</html>

The final source file resides on the original domain (marked as [3] in the figure above) and contains some javascript to strip out the height parameter and then pass this on to the function on the main page that resizes the iframe. It is referred to in the code above, as the content of the file at http://example.org/xssEnabler.html – and whilst it is saved as a .html file, it contains just the code you see below.

<script type="text/javascript">
	function getFirstParamFromLocation() {
		var pair = window.location.search.substring(1);
		var parts = pair.split('=');
		return parts[1];
	}
	var nHeight = getFirstParamFromLocation();
	try {
		window.top.resizeIframeHeight(height);
	} catch(e) {};
</script>

Obviously you would not be using example.com and example.org for your solution, they are used merely to identify the different domains you would use for each file.

ReferenceError: console is not defined

It turns out that this is by design. If you want to make use of the console object that Firebug offers, you need to do so with a call to window.loadFirebugConsole() first.

A little bit of testing, and the following code can be safely put in your javascript source to enable use of the Firebug console object safely (without breaking other browsers).

if (window['loadFirebugConsole']) {
	window.loadFirebugConsole();
} else {
	if (!window['console']) {
		window.console = {};
		window.console.info = alert;
		window.console.log = alert;
		window.console.warn = alert;
		window.console.error = alert;
	}
}

Whilst you are at it, why not check out some of the other nifty commands available on the Firebug console object at the Get Firebug website.

As with most things, there are several ways to do this conversion. I’ve used parseInt() a lot in the past to convert a string into a number (although strictly speaking I am converting to an Integer rather than just a Number when using parseInt()), but recently ran into some strange behaviour that I wanted to understand.

var l_sValue = "07";
alert(parseInt(l_sValue)); // alerts 7

This seems to work fine, the string represents the number 7, and the parseInt() correctly parses it into the integer 7. Now we change the string value and something strange occurs:

var l_sValue = "08";
alert(parseInt(l_sValue)); // alerts 0

This is obviously not the expected result! The solution is to use parseInt() correctly, and pass through both parameters (the second parameter is the number base to use).

If you do not pass in the second parameter (the base, or radix) then Javascript will default to base 10, unless:

• the string starts with ‘0′, then it will default to base 8 (octal)
• the string starts with ‘0x’, then it will default to base 16 (hexadecimal)

Because the string we used above started with ‘0′, Javascript defaulted to use base 8. The reason we see 0 being returned from parseInt(’08′) is because 8 is not a valid number in octal (we would count in octal 0, 1, 2, … 6, 7, 10, 11, 12, … 17, 20, 21, …).

Now look what happens when we pass in the second parameter and use (the more familiar) base 10:

var l_sValue = "08";
alert(parseInt(l_sValue, 10)); // alerts 8

Lesson for the day: always pass in the base when using parseInt() to parse a string into an integer.

In the past, browsers have used various techniques to handle the script contents… and this has had a long lasting effect on the way we use this tag in our current projects. The most abused attribute remains in common use today (even though has been deprecated in HTML 4.01 and XHTML 1.0 Strict) – the language attribute. Instead of specifying the language, it is now standard to specify the MIME type through use of the type attribute – and it is important to note that this is the only required attribute for the script tag.

If you are including some Javascript in the document itself, then you would use a construct similar to this:

<script type="text/javascript">
alert("Hello world!");
</script>

If you are delivering this content in a document that is using an XHTML doctype, then you should comment the data between the script tags (if you are unable to include it as an external Javascript file – see below) so that it is not parsed client-side. In the past you would often see a similar technique in use to “hide the code from older browsers” (note that the following example shows the correct way to use comments in an XHTML document using CDATA):

<script type="text/javascript">
//<![CDATA[
alert("Hello world!");
//]]>
</script>

There is no point using the CDATA comments above in a non-XHTML page at all. Nor is there any value in using the following kind of comments (whether you are working on an HTML or an XHTML document). This commenting was widely used to prevent “old browsers” seeing the Javascript. Nobody uses these “old browsers” for regular web use (and if they did, most web sites that use Javascript would break anyway)… so there is absolutely no point in including the comments:

<script type="text/javascript">
//<!--
alert("Hello world!");
//-->
</script>

If you are including an external Javascript file in the document, then you would use a construct similar to this:

<script type="text/javascript" src="helloworld.js"></script>

The only difference between inline and linked Javascript is that the latter uses the src attribute to specify where the linked Javascript file resides.

When writing well formed documents, you should include information about the default scripting language. This can be done using a meta tag in the document:

<META http-equiv="Content-Script-Type" content="text/javascript">

This is good practice, but is not required – especially if the server is already serving linked Javascript files as “text/javascript” (or more correctly: “text/x-javascript”).

JavaScript is an object-based scripting programming language based on the concept of prototypes. The language is best known for its use in websites, but is also used to enable scripting access to objects embedded in other applications.

It was originally developed by Brendan Eich of Netscape Communications Corporation under the name Mocha, then LiveScript, and finally renamed to JavaScript.

JavaScript has a C-like syntax.

Here is a short list of some things that Javascript is not: