EasyCheckboxes: dojo.query and Greasemonkey

I’ve written a useful script for Firefox and Greasemonkey called EasyCheckboxes.  It makes it more convenient to work with multiple checkboxes on a page, enabling you to select, deselect or toggle groups of checkboxes. It will also work with all web pages.

See the video below for more info, or you can install it right now by clicking here, or by visiting the script homepage at http://chofter.com/apps/?n=easycheckboxes

Context Aware Selections

One of the most useful features of EasyCheckboxes is that it is context aware.  It figures out what checkboxes are related to the one you chose, and only changes the state of those. This is useful if you have multiple columns of checkboxes, and you only want to check all inputs in one column.

Of course you can also change the values of all checkboxes on the page.

Using Dojo’s query engine, Acme, in Greasemonkey

If you’re not interested in the techie details, you can stop reading now.

Since version 1.3 of the Dojo Ajax Toolkit, it provides a standalone DOM query engine called Acme.  I compressed this down to a single line of code, and inserted it in my GreaseMonkey script.   I previously tried using the Sizzle query engine, but it had too many issues with Greasemonkey, the main being that it sometimes crashed the browser.

Using it is very simple.  Simply call:

acme.query(“.someClass”, unsafeWindow.document);

And it returns an array of the matching nodes.

Using dojo.query & Greasemonkey to skip welcome screens

I posted a couple of weeks ago on how I used the Sizzle CSS selector engine in a Greasemonkey script to skip annoying “Welcome Screens”, see it here, or check out the very handy script here.  However, there were a couple of issues with using Sizzle:

• It had to be inserted in the main page’s JavaScript context, otherwise it would not work.  This is obviously bad as it takes it out of the Greasemonkey sandbox, and potentially could break functionality on the page in question.
• On some pages it crashed the browser.  Not good.

So, I’ve replaced it with the Dojo standalone library, Acme.  Some advantages it has over Sizzle:

• It’s arguably faster
• It doesn’t have to be put outside the Greasemonkey sandbox, so no interfering with the page code.
• It doesn’t crash the browser

You can get the uncompressed version of Acme here – http://archive.dojotoolkit.org/nightly/checkout/dojo/_base/query.js

If you want a compressed version, that works independantly of Dojo, you can compress that file to a single line using the YUI compressor at http://www.refresh-sf.com/yui/

Dojo & GreaseMonkey == DaftMonkey

Given that I’m looking for a new apartment, and I live in Ireland, I use the property search website Daft.ie.  Everyone does.  However I wasn’t very happy with how slow it is to scan through the many results that match my meagre budget.  I realised that it could be readily fixed with GreaseMonkey, using the Dojo Ajax Toolkit to make life easier when it comes to parsing the page, adding effects etc.

The result is DaftMonkey.

I wasn’t even sure if Dojo could be used from within a GreaseMonkey script, as it sandboxes away the custom script code.  However, with a little hackery it was (more or less) possible.  The steps I took were:

1. Set up the djConfig parameter in the host window to tell Dojo that the page had already loaded, using unsafeWindow.djConfig = {afterOnLoad: true};. unsafeWindow is what GreaseMonkey calls the normal, non-sandboxed window.
2. Added the <script> tag for dojo.js to the head of the document.  In this case I used the dojo.js.file hosted on AOL’s CDN servers – see http://dev.aol.com/dojo .
3. Now you have to wait for Dojo to load.  This can be done with a simple setInterval function call, checking if unsafeWindow.dojo exists or not.  (Update: thanks a comment from James, this has been changed to use the djConfig.addOnLoad function)
4. Once Dojo is loaded, you can call a function kicking off whatever it is that you  script is supposed to do.  In this case, I wanted to add a bunch of DOM nodes to the page (which you can do without Dojo), and add some cool effects, so I also included the dojo.fx bundle.
5. Copy the dojo variable back into the sandbox window using var dojo = unsafeWindow.dojo, otherwise you’ll have to refer to it as unsafeWindow.dojo all the time.

Screen Scraping With dojo.query

A lot of the features of DaftMonkey rely on asynchronously fetching remote HTML pages and scraping the required data from them.  The approach I used for this was:

1. Perform a remote request using GreaseMonkey’s native Ajax function GM_xmlhttpRequest.  This works more or less the same as dojo.xhrGet, and I saw no reason to not use it.
2. When the text is returned, create a DIV, and absolutely position it far to the left.  Fix it’s size to just one pixel so it doesn’t mess with the scroll bars.
3. Set the innerHTML of the DIV to the text you have retrieved.  Congratulations, you can now use dojo.query to find whatever nodes you need.  e.g. to find all images inside anchor tags, use dojo.query(“a img”, tempDiv).  Note the second parameter, this tells Dojo to only search inside the temporary DIV we created, and not the whole document.

Some other site-specific things were required as part of the screen scraping process.  Many of the sites had iframes included, and as soon as you add those to the temporary DIV, they start loading another page.  This was a nasty performance hit, so I had to remove them from the HTML string before setting the innerHTML of the temporary DIV.

Problems

One problem I found is that calling dojo.declare didn’t work from inside a GreaseMonkey script.  I don’t know why.  Therefore widgets had to be defined the old fashioned way.

A second problem was more related to the website I was writing the script for, Daft.ie.  The entire site is programmed using TABLES!  Seriously, there’s barely one or two DIVs on the page, with practically no CSS either.  This makes it quite difficult and brittle to screen scrape using dojo.query, as there’s really no classes to match.  Still it was possible, but could break relatively easily if the site layout is changed.

Get the Source

You can get the entire source for the script at http://userscripts.org/scripts/show/41105 .

To read a bit more about DaftMonkey, I’ve put up a page about it at http://www.chofter.com/apps?n=daftmonkey .

Deleting DOM nodes with Dojo

This is a quick and simple tip for deleting multiple DOM nodes in JavaScript using the Dojo Ajax Toolkit.

A common pattern in non-trivial Ajax applications is the need to delete many nodes that may or may not have been created.  The code to do this without Dojo (or a similar library such as jQuery) would look something like the following code (assuming nodes are identified by ID):

var nodeIDs = ["node1", "node2", "node3"];
for (var i = 0; i < nodeIDs.length; i++) {
 var node = document.getElementById(nodeIDs[i]);
 // Verify that the node actually exists, otherwise an error occurs
 if (node) {
  node.parentNode.removeChild(node);
 }
}

This is of course a bit messy.   It would be infinitely messier if you needed to match nodes not by ID, but by another method such as by class name, relative position to it’s parent or sibiling nodes etc.

To achieve the same in Dojo, use this simple code.

var nodeIDs = ["#node1", "#node2", "#node3"];
dojo.query(nodeIDs.join(",")).orphan();

Update: There is a bug in Dojo that means that if the node with ID “node2″ does not exist, “node3″ will not be deleted.  (Thanks to Pete Higgins for letting me know). Instead use the following code:
dojo.forEach(arr, "dojo.query(item).orphan();");

Very simple, and much smaller and cleaner than the previous example.  It also scales very well to match nodes using CSS selectors, not just by ID.  For example, to delete nodes both by ID and class name, use the following code.

var nodeIDs = ["#node1", "#node2", ".className1", ".parentClass .childClass"];
dojo.query(nodeIDs.join(",")).orphan();

Update: as with the first example, replace the second line with:
dojo.forEach(arr, "dojo.query(item).orphan();");

For more info on the cool features of dojo.query, see the docs at http://docs.dojocampus.org/dojo/query .

Dojo Ajax Demo Engine released

A great new demo engine has just been released for the Dojo Toolkit. Check it out at http://dojocampus.org/explorer/. It is based on the initial attempt at a demo engine I wrote a few months ago, but has since been updated with new demos, and made infinitely more sexy by css/theme master Nikolai Onken.

The features include:

• Demos for all three Dojo projects – Dojo (the base toolkit), Dijit (widgets) and DojoX (all that is newest and coolest) .
• Source views for all demos. Not only do we show what Dojo can do, we show you how to do it! The source views also benefit from the very cool dojox.highlight project, which provides client side syntax highlighting.
• Addressability - you can link directly to a demo, as I did with the dojox.highlight link above.
• Search feature – a combo box that you can use to quickly find a demo on any subject. For example, type “image” into the box, and you’ll be shown a list of all demos to do with displaying images, such as dojox.image.Gallery, dojox.image.SlideShow etc.
• Cool animated menus – totally aesthetic I know, but a very pretty addition by Peter Higgins. The menus separate the three projects, providing easier, clearer navigation.
• Link hierarchies – each set of demos can have links attached to it, for example to extra tutorials or documentation. If you click a parent of that demo, you are shown all links of all children of that section. For example, click on the DojoX link on the top of the page, and you’ll be presented with a list of all links to all DojoX projects.
• Browser Back Button management. Using the dojo.back package, you can navigate back and forward through the application using the browser’s back and forward buttons.

The demo engine is hosted on the extremely cool Dojo Campus website, which is a new learning resource for all things Dojo. It contains videos, tutorials and much more.

This version of the demo engine has many many examples in it. However, it is only the beginning, and there is a lot of room to add more content. The next step is to open the development process for community submissions of all the cool things people have done with Dojo. We will be making available the demo engine on Subversion, and writing development and submission processes to make it as easy as possible for people to contribute.

This is gonna be big!

Update: see http://ajaxian.com/archives/dojo-mini-and-the-feature-explorer for the Ajaxian post.
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt

Dojo Demo Engine Update

A short while ago I posted about the demo engine I’m writing for the Dojo Ajax Toolkit. Click here to read that post or go to http://www.skynet.ie/~sos/js/demo/dojo/dojoc/demos/featureexplorer.html to see it in action.

Update: Version 1.0 of the demo engine has been release. See here.

Features

Since that post, quite a lot of work has gone into both the features and the content of the demo engine, and the development process has solidified nicely. Some of the features include:

• Tree navigation. A dijit.Tree widget, reading from a remote JSON data store is used to navigate the various demos.
• Search feature. A dijit.form.ComboBox widget, reading from the same JSON data store as the tree, can be used to dynamically search for demos by matching any part of their name.
• Theme switcher. A dijit.form.ComboBox widget is used to switch between the CSS styles that Dojo provides.
• URL addressability. Using a hash identifier (e.g. #Dojo_Query_By%20Class) in the URL of the demo engine causes it to open that demo when it has finished loading. For example, if you click this link, it will open the dojo.query demo showing you how to select nodes by class name. Opening any demo changes the URL in the browser to the URL for that demo, for easy bookmarking.
• Integrated build process. A simple build script is integrated with the Dojo build process. It builds a JSON data file listing all the existing demos and their respective files. It also builds files with URL links for each demo.

Content

To date, a lot of content has been added. Many, many widgets in Dijit and DojoX
have have been added, including the majority of the Form Controls.

The latest, pretty cool additions have been the IO and dojo.query demos. These cover things such as:

• Performing a XMLHttpRequest request
• Using an iFrame transport
• Submitting a form asynchronously
• Loading remote JavaScript files from another domain
• Selecting nodes using CSS selectors with dojo.query
• Performing operations on the NodeList returned from dojo.query
• Attaching events to the NodeList returned from dojo.query

File Naming Scheme
A simple file naming scheme is used to add content to the demo framework. Each folder beneath the root folder represents a demo. Each file in a folder must be named the same as the folder, with five possible extensions. For example, given a folder with the name ‘Button‘, the possible files are:

• Button.html – this contains the demo to be displayed. Any JavaScript code inside <script> tags is executed, and any <link type=”text/css”> and <style> tags have their CSS loaded. The executed code is shown in the View tab, and and the source code is shown in the XML tab. The <html>, <head> and <body> tags are not required.
• Button.js – this contains pure JavaScript code that performs the same operations as Button.html, if applicable. It is not executed however. It is shown in the JS tab.
• Button.txt – this contains the text description of the demo. It is loaded above the tabs.
• Button.links – this contains a JSON array of URL links. The build script transforms these links into HTML, and the result is loaded into the Links tab. One neat feature of this is that all links from sub folders are integrated with the parent folder and displayed in a nested structure. Do, for example, clicking on Dijit will show all the links for all widgets in the Dijit project.
• Button.full.html – this is standalone demo, that is designed to run outside the demo engine. The View tab provides a link to the external file.
• sort.txt – this contains a comma separated list of the child folders contained in this folder. It specifies the order in which to display the child demos in the tree. If this file is not specified, then an alphabetical ordering is used.

All of these files are optional. If a file in a folder does not match this naming scheme, it is assumed to be some kind of resource that the demo needs, such as an image or a JSON data file. In this case, the file can be named whatever you like.

The tree structure in the demo engine mirrors the folder layout.

Still To Do

There remains quite a lot of work ahead. There are a few bugs remaining, some more cross browser testing is needed, and of course more content is required, particularly the base Dojo package.

In the relatively near future this should be opened up to the public for development. The Dojo folks are setting up a source control server for community additions, and this demo engine should be part of that. Once that is done, people can start adding all sorts of cool stuff!
Share this post:digg it|kick it|Email it|bookmark it|reddit|liveIt