The CRM Grid – A Microsoft CRM Blog

Greg Owens’ rose-tinted MS-CRM mumblings

Archive for October, 2007

More thoughts on managing your JavaScript code

Peter Maude made an interesting post, quite some time ago now, considering how one might manage the reams of JavaScript code that could potentially accompany a highly customised MS-CRM deployment.

I’ve pondered over this recently as I move from development to a live deployment and I migrate my custom JavaScripts from standalone .js files into the entity forms themselves. Presently I have some standard wannabe-global code for generic functions (such as show/hide elements of the UI), lots of entity-specific code in the onLoad event and often up to a dozen smaller script files which handle onChange events in various form controls.

Keen to make the effort to at least try and be in a supported environment, it strikes me that the simplest method is to put all of my code in the onLoad event handler and use the “attachEvent()” method to allocate functions to the appropriate form controls (thinking about it, this probably isn’t supported either…!). For example the code I currently use for each onChange event has its own .js file. I can simply copy this code, wrap it in an arbitrary function wrapper in the onLoad event handler and then attach that function as the onchange event for the field I want:

var fieldA_function = function exampleOnChangeFunction()
// function to be executed onChange of myfield A
alert('Field value is: ' + crmForm.all.new_myfielda.DataValue);
crmForm.all.new_myfielda.attachEvent("onchange", fieldA_function);

I haven’t tested this, but right now it feels logical enough. At the very least you will never have more script sources to manage as you have entities. I’d be interested to know your thoughts or ideas.

I’ve been wondering whether it might be possible to store code in a custom entity, e.g. called JavaScript and calling the code direct from the database… More on that when I’ve proven whether it’s possible or not!

Prevent caching of Javascript include files during development

Recommended JavaScript Book!

I'd also like to highly recommend this JavaScript book by Douglas Crockford - it will definitely improve the quality of your JavaScript development experience!

Surely everyone that does their own clientside Javascripting of the MS-CRM interface is already using the technique described by the almighty Ronald Lemmen to link to .js files to speed up the development process, since it removes the need to republish your entity forms over and over after each scripting change. Although unsuited for use in a production environment (for various reasons), this method has undoubtedly saved me hours in development time.

What I couldn’t understand though was why my updates often didn’t take effect, despite updating and saving my script files and even closing my browser. I even looked around for some evidence that I wasn’t the only one on the planet with this problem. Google suggested I was, so I had to find my own solution.

The problem appeared to be that the .js file was being helpfully cached in IE. By clearing my cache and fully reloading the page, I could solve the problem. Still, it was annoying. My preferred solution is a bit ugly but works a treat – when calling the JavaScript file, ensure that the script source is located at a unique URL each time the page loads. I use the getTime() method of the Date object to give a totally unique URL for that moment in time. The harness to load all my JavaScript files now looks like this:

var dt = new Date();
rndURL = "<script src='full_path_to_source_file.js?random='" + dt.getTime() + "' language='JavaScript'>";
st = document.createElement(rndURL);
h = document.getElementsByTagName('head');

Obviously this script is entirely unsupported by Microsoft, but if you happen to become the second person on the planet to experience the same caching issue I did, this just might save you some time.

Don’t forget that the first time you paste this code into your form onLoad event, you’ll need to republish your form, flush the browser cache, restart IIS, turn around three times then hit F5 in IE before the randomising magic works for you.

Testing the water

I’m under no illusions – no one is reading this blog now or indeed for some time, so this post is for my own purposes – a reminder that I have something interesting relevant to post on JavaScript caching during the development cycle.