Speeding up the delivery, as a Content Delivery Network (CDN) is used to ensure that the server is as close as possible to the client, and

The more people who use this the better, as the same Dojo files will be cached when users move from site to site, as they’ll all be downloading the AOL hosted files.

Gzip compression as standard, so the files are as small as possible

Additionally, since release 0.9 onwards, the main Dojo JavaScript file, dojo.js, is always exactly the same, whereas in previous released it changed for every developer who built it.

However, the problem comes in where you want to use your own custom code with the hosted Dojo code. This is because the hosted code uses Dojo’s loading system to dynamically load the resources needed on the page, and this will read the files from AOL, not your server (as you would expect – it knows nothing about your server). If you want to build custom layers to improve performance, the remotely hosted Dojo will not be able to find them.

So, the solution I generally tend to use is to put the AOL dojo.js on every page, and tell Dojo to load any other required files from my own server. To do this, set the baseUrl parameter on the djConfig attribute for the JavaScript file to the folder where Dojo is stored on your server. E.g.

Notice here that the file I load is dojo.js, the normal version, not dojo.xd.js, which is the cross domain version capable of loading files from AOL.

After doing this, you can then include whatever custom built layers you like onto an particular page. For example, if you have a layer built for the dojox.image.Gallery widget called /js/dojo/dojox/image/Gallery-layer.js, you can load it either dynamically:

and it should work just as if you were using Dojo from your own server. Only of course you are not – AOL is serving up that file, and in many cases users will already have cached that file, speeding up your site quite nicely.

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:

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