October 1st, 2007
Javascript on Demand: part two
- Initial page load is faster
- Overall bandwidth usage is less, since only the JS that is required is loaded
- XSLT is easier to create (no more <script>s in <![CDATA[ ]]>)
- markup becomes more purely semantic
- New JS behaviours can be deployed separate from other deployments without incident
- It bypasses the “same domain†policy - you can even host javascript snippets on a separate server or domain
- It snuggles more intimately with CSS
<head>
<script src="js/mootools-release-1.11.js"></script>
<script src="js/bootstrap.js"></script>
</head>
The Bootstrap script does a couple things:
- Uses the “domready†object to trigger itself. In addition to its obvious utility, it also ensures that Mootools is loaded.
- Applies a series of selectors to see if any special JS-dependent elements are present in the DOM
- Loads a JS asset for any that are found
window.addEvent('domready', function(){
if ($$('a.external')){
new Asset.javascript('js/external.js', {id: 'external'});
}
if ($$('.editable')){
new Asset.javascript('js/editor.js', {id: 'editor'});
}
});
Explanation:
On line 2, we check if the current document contains an element matching “a.externalâ€.
If it does, then we load the JS asset controlling the behavior of external links (which is to open in a new window)
The condition needn’t be just a $$ selector. You can include an asset depending on the time of day, the user’s browser version, the number of links on the page, authentication, or … anything.
If the page has an external link on it, then we want to attach an onclick event to it. This is so much more elegant than peppering your HTML with "onclick" events in the markup. And if we ever want to change the behaviour of those links, we don't have thousands of <a> tags to find and edit.
Here is the asset we're loading when "a.external" is found:
external.js
window.addEvent('domready', function(){
var xlinks = $$('a.js-external');
for (var i=0;i
- Everything starts with the domready trigger. This ensures that Mootools is loaded before going on. Even though we checked for domready in the bootstrap, we need to do it again here, since the domready event will re-trigger new onload events when the event is added. The actual asynchronous event scheduling is a little tangled with all these onload events loading and triggering, but this works.
- It returns false. Most JS behaviours should, so we can have one set of actions in the HTML for non-JS agents (form, action, href, postback, etc), and an enhanced set for JS-enabled agents which may replace, manipulate, or augment the DOM
- It adds events to elements. Those events can be really simple or very complex, they may trigger the creation of other elements, behaviours could involve AJAX or JSON, etc. But it all starts with adding events to existing elements – these must be the same elements (using identical selectors) that were checked for existence in the bootstrap.
Using className to pass config variables to a script
When an element’s behavior is simple, a simple class name is all it takes to identify it and load the required JS asset. However sometimes a behavior will require some config options or parameters. For instance, you might create a <textarea> which enforces a maximum length. But what is the maximum length for this field? You can pass additional modifiers via additional class names.
One cool advantage of this technique is that the additional class name will modify the behavior of an element, but it can also modify the way it is styled via CSS. Thus an element that acts with behavior A can be styled with style A, while the same element with behavior B can be styled with style B. Events within the behavior that affect styling will add, modify, or remove classes as appropriate, offering a tighter weld between JS behaviours and CSS styling.
class names are generally not used for default values for an element or script; they are used to pass in config values, like how many, what limits, which other elements are grouped or dependent, etc.
Consider this hypothetical markup:
<input type="checkbox" class="disabler disablergroup-d12" />Cheese
<br/>
<div id="d12">
Choose cheeses to include:
<input type="checkbox"/>Mozzarella
<input type="checkbox"/>Cheddar
<input type="checkbox"/>Gouda
</div>
The markup for the checkbox indicates that it has a behavior of “disablerâ€. The disabler function looks at the className and finds a “disablergroup-†class, and knows that the script should toggle the “disabled†attribute of any <input> elements found within “#d12â€.
This technique seems elegant when there are only a few script parameters; with large numbers of script parameters it may become nasty, so one must consider each as they are built.
As mentioned, I haven't yet determined if this technique offers improved performance, though it is clear that it enables cleaner code and more purely semantic markup. In a complex web application using a lot of AJAX, JOD would really come in handy - I'm just not sure whether it is sensible to use it on a (mostly) static web page.
enjoy
Filed under Uncategorized
October 10th, 2007 at 10:18 am
update:
refactored the bootstrap function using a function; this version has some performance benefits, like using $E instead of $$, which spares the client from storing a large array of elements in memory.
// bootstrap.js
function addscript(selector,script,scriptid){
if ($E(selector) && !$(scriptid)){
new Asset.javascript(’/js/’+script, {id: scriptid});
}
}
window.addEvent(’domready’, function(){
addscript(’a.js-external’,'js-externallinks.js’,'js-externallinks’);
addscript(’.js-editable’,'js-editinplace.js’,'js-editinplace’);
});