Dojo vs Dijit - files to include or reference?

Question

I've been reading O'Reilly book "Dojo - The Definitive Guid" but somethings are still not definitive to me.

They talk about "bootstrapping" and getting the dojo.css from the AOL CDN".

When I'm testing on my machine, should I use the CDN? Or should I wait and use that only when I deploy?

Secondly, the book talks about CDN for dojo, but not for dijit.

I'm developing on Google App Engine (GAE) - so having the 2000+ Dojo/Dijit files in my Javascript directory is a little annoying, because it slows down my upload to GAE each time.

Firebug is giving me this error: GET http://localhost:8080/dijit/nls/dijit-all_en-us.js 404 not Found GET http://localhost:8080/dijit/_editor/plugins/FontChoice.js 404 not Found

I downloaded the sample from here: http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html?theme=soria and I'd like to "simply" get it to run on my machine under local google app engine (which is the localhost:8080 that you see in the URLs above).

I see this statement which probably is causing the second 404 above: dojo.require("dijit._editor.plugins.FontChoice");

One other error: cannot access optimized closure preload("en-us") dijit-all.js (line 479) anonymous("dijit.nls.dijit-all", ["ROOT", "ar", "ca", 40 more... 0=ROOT 1=ar 2=ca 3=cs 4=da 5=de 6=de-de 7=el 8=en 9=en-gb])dijit-all.js (line 489) dijit-all.js() dojo.i18n._searchLocalePath(locale, true, function(loc){\n

To continue for now, I'm going to try to copy the entire dijit library, but is there a solution short of that?

My current script includes look like this:

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

<script type="text/javascript" src="/javascript/dijit-all.js" charset="utf-8"></script>

I got the dijit.js file by copying and renaming dijit.js.uncompressed.js to dijit.js.

Answer 1

You have a few options actually:

1. You could use the CDN for everything (though using the full source locally does give you better error messages). Google has them as well. Dijit is here: http://ajax.googleapis.com/ajax/libs/dojo/1.3.2/dijit/dijit.js FYI. This has many advantages in my opinion. User caching of the JS being the primary one.

2. Build a layered file. I think the O'Reilly book has a section about it but the PragProg book is better in this regard IMO. There's also this doc on dojocampus.org about building. This will trim down the files you need to upload to GAE and speed up your app loading. This is actually what I do in order to cut down on HTTP requests.

3. Keep doing what you are doing. :)

Regarding the errors you are seeing about 404 for en-us files are essentially harmless. Here's a better description.

You also might be reloading dijit files by using dijit.uncompressed.js and dijit-all.js and causing problems in the process...but I'm not sure about this one.

Answer 2

I just want to clarify that when using CDN all you need to include is the main Dojo script. The rest will be pulled in automatically when you dojo.require() them.

If for some (technical) reasons you don't want to use the X-Domain loader (CDNs use this type of loader), you can do a custom build (well-described in many places). After the build you copy only relevant files to your server. No need to copy all 2000+ tests, demos, unused DojoX projects, Dijits and so on.

During the build you will create a single minified file (or a few layers), which will include all Dojo JavaScript code you use. If you use Dojo widgets, their templates will be already inlined, so you do not incur hits for them. As part of the build CSS files are combined together and minified too. So literally in most cases you will have just two files: a Dojo layer, which includes everything + your custom code, and a CSS file. In more complex cases you may have more files, but usually we are talking about handful.

How to make sure that everything is in the build? Fire up your favorite network analyzer (Live HTTP Headers, Firebug, Fiddler2, or Charles Proxy would do fine) and see if you hit any files outside of your build. If you do — include them in the build, or try to figure out why they are requested, and eliminate these requests (some localization-related calls are fine).

Personally I would start with the CDN option — works well, no hassle, hosted by somebody else with fat pipes.

Answer 3

To address your first question, use the full source version locally for development, so that you can get clearer debug info which points to a legible line in source, rather than the single line the minified version is reduced to. Use the CDN for production.