When you begin creating a mapping application using the ESRI JavaScript API, there’s a good chance that you will choose Dojo as your framework, since the ESRI JS API is built on top of Dojo anyhow. Whether you begin with the Sample Viewer from ArcScripts or decide to roll your own solution, you will quickly encounter dependencies on Dojo files which are not “baked in” to the core ESRI JS API build.
How Dojo handles dependencies beyond those satisfied in the original JS imports is a topic for another post, but suffice to say that it creates a blizzard of HTTP requests that slows down the loading of an application. What we want to do is use Dojo’s build system to concoct a single (generally) JavaScript file that has all of the dependencies included by default.
This turns out to be a bit complicated for a couple of reasons:
- the ESRI JS API already includes much of the Dojo code we need in a packaged form, and we don’t want to duplicate that code in our build.
- Dojo cannot resolve any dependencies on ESRI core modules, since we don’t have access to the JS source.
To tackle the first challenge, we can use the concept of discardable layers in our Dojo build profile. Our first layer (compiled JavaScript file) in the Dojo build is going to be exclusively comprised of Dojo modules that are already included in the core ESRI JS API build. We add this first layer as a dependency of our main layer to ensure that we don’t duplicate code. This unfortunately requires a bunch of manual CRTL-F work inside the ESRI JS API to actually find out what they’ve included in their build, but it’s not all that bad. It would be nice to see their Dojo build profile…
The second problem is resolved in a way that seems non-intuitive at first, but makes sense when you think about how Dojo loads required modules. We need to REMOVE all Dojo.require statements that reference core ESRI JS API classes. Commenting them out is nice since it preserves the original Dojo.require’s as code documentation. You might think this would cause the application to stop working entirely, but that’s not the case. When working with the ESRI JS API, all of the core modules are imported into your page with the initial script import, so there’s nothing Dojo needs to do when you specify your require. It’s generally still good practice for a few different reasons to continue using Dojo.require statements, but the core ESRI requires will prevent your build from running.
Have a look at the integration of Geocortex Essentials 2.0 with the JavaScript sample viewer on resources.geocortex.com if you want to see the pre-built application in action. I’ve left out many gory details, so feel free to contact me if you’d like to get some more detailed info, or even a sample Dojo build profile.
I’m getting this error:
release: Interning strings for :
release:
js: “../../dojo/./_base/json.js”, line 78: exception from uncaught JavaScript throw: Error: Can’t serialize DOM nodes
I’m not sure what could be the problem, though it appears to be during the string internment phase. Though not ideal, you could try to see if it builds when adding the extra internStrings=false command-line parameter to your build command.
I haven’t seen the same error as you’ve got when using Dojo 1.2.3, 1.3.1, or 1.3.2 so perhaps it’s related to differences in our environments. I’m working with the JS API version 1.4 and Java 1.6.0_14.
Sorry to bring up an old post, but I am having issues when attempting to use the custom javascript library that I have built. The build goes smoothly, but when I reference my custom library (in addition to the ESRI JS API), I am getting the following error: uncaught exception: Could not load cross-domain resources: dojo.nls._en-us
It appears to be looking for this file within the ESRI JS API instead of my own custom library. Any ideas as to why? (By the way, my custom build creates an nls folder with the appropriate files. The CUSTOM_LIBRARY_en-us file does exist does exist in the nls folder).
Hi Isaac – I have the same problem – did you resolve? driving me potty.
Ditto for me. Any luck?
I resolved it, sort of. It was quite a mission and the fix is a bit of a hack but it works and thats all you care about by the time you have reached this stage!
Basically what you have to do is copy and paste the nls strings over to your compressed file yourself, thereby avoiding the need for the x-domain call.
Heres an extract from my compressing instrucions;
Now, you have to do the follow fix to prevent a wierd x-domain call.
1. Open the file release/version/dojo/nls/4c_en
2. Open /dojo/4c.js .Do this in Notepad with wordwrap on.
3. At the end Remove the call to dojo.i18n._preloadLocalizations
3. Copy and paste the contents of nls.4c_en into the end of the file
Thanks for the work-around, Richard. I just wish that I knew what was causing this in the first place. I have plenty of other projects that build just fine without this error message.
After doing the Dojo build I was having problems with my mapping application opening in Firefox and failing in IE due to the ‘Could not load cross-domain resources’ error. I noticed that the ESRI JS api layer had an ‘en-gb’ locale. So,
was working for Firefox but not for IE. I finally resolved this by getting Dojo (the dojoConfig object) to override the browser’s locale before referencing the Dojo localisation bundle.
dojoConfig = { parseOnLoad: true, locale: “en-gb” }
At the moment this is working well.
regarding exception from uncaught JavaScript throw: Error: Can’t serialize DOM nodes
This took me a long time to suss out!
http://bugs.dojotoolkit.org/ticket/9711
Annie I`m waiting for more articles…
I`m waiting for more articles…