Integrated Development Environments

At the high end of the spectrum, Integrated Development Environments, or IDEs support a wide range of web development activity, including editing JavaScript and HTML files, deploying code to servers, and integration with existing features like source control. In addition, some include runtime tools and browser integration to assist in debugging.

Cross-Platform, Eclipse-Based

• Aptana - Extremely strong JavaScript support, good support for many common server-side languages, and integration for Dojo.
• MyEclipse - MyEclipse Professional contains a JavaScript editor and debugger. The debugger can set breakpoints, inspect variables, and single step within its own Web 2.0 Browser, based on Mozilla/Firefox.
• ATF - The Ajax Tools Framework contains similar tools as MyEclipse, and adds AJAX toolkit "personalities". These are essentially snippets for the common idioms for a toolkit. The Dojo personality is included, but is not yet updated for 0.9.
• Adobe JSEclipse, formerly a product of Interakt, is a free JavaScript editor. Like ATF, it includes code completion idioms for Dojo, but does not include the debugger.

Windows

• Visual Studio .NET bundles the JavaScript editor and debugger with the other languages. This is especially useful when writing data services in ASP.NET and client-side scripts with Dojo.
• Visual Web Developer Express is a free, scaled down version of the web portion of Visual Studio. JavaScript editing and debugging is supported.
• Microsoft Script DebuggerAn extremely scaled-down and outdated debugger, but familiar to many.

Browser Addons

Mozilla/Firefox

• The Firebug is the debugger of choice for Dojo and Firefox. Consult Cheap Debugging for details.
• JavaScript Debugger, a/k/a Venkman has been around for years, and has adherents. Venkman seems to be dormant, gaining no new features but being ported verbatim to new versions of Firefox.
• Live HTTP Headers is useful for debugging HTTP traffic . Although Firebug is good for analyzing HTTP traffic within the page, as in XHR, Live HTTP Headers excels at between-page HTTP requests.
• The Web Developer Toolbar is a favorite of Web Designers, and includes rulers and positioning features that Firebug does not.

Internet Explorer

• IE Web Developer is a commercial product with Firebug-like features such as JavaScript debugging.
• IE Developer Toolbar, a free download from Microsoft, is useful for page design.
• The Microsoft Script Editor integrates with Internet Explorer and is available as part of office 2003. It is not included in the default install but you can get it from the installation cd's.
• Web Developer Helper - HTTP logging, script debugging and a DOM inspector.

Safari

Drosera is the "native" JavaScript debugger for Safari, and is written by the folks from Webkit, on which Safari is based. The Safari Developer FAQ has some general information about developing with Safari, as well as instructions on how to turn on a debug menu that allows showing a JavaScript console.

Traffic Analyzers

Many problems can be resolved by watching the traffic between the browser and the server. While IDE's and web add-ons analyze traffic, the following standalone programs are more heavy-duty. If you are having any problems with XHR or with js/html/css/jpg files not loading as you would expect, this is often the best way to diagnose them quickly. Also if you are having problems with required files not loading then this is a good starting point to find out why.

• Fiddler is a fantastic HTTP header and content inspector for Windows. It understands HTTP and presents the information very clearly (once you get used to its slightly quirky interface). Well integrated with IE, but work s with any browser. With FF a useful extension to help use Fiddler is the Switch Proxy extension (scroll down that page to find it).
• Wireshark (formerly Ethereal) is great for sniffing all kinds of network traffic.

Using Dojo with Maven

• http://download.dojotoolkit.org/maven2-snapshot/
• http://download.dojotoolkit.org/maven2/

• dojo toolkit release as a zip, tar.gz and tar.bz2
• dojo toolkit packaged as a java war file ready to serve. The war includes a filter that sets the Cache-Control header to encourage browser caching.
  
• cometd artifacts for java API and cometd example war

Building Dojo with Maven

svn co http://svn.dojotoolkit.org/src/view/anon/all/trunk dojo
cd dojo/util/maven
mvn 

Using Dojo artifacts

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-dependency-plugin</artifactId>
  <executions>
    <execution>
      <id>unpack dojo</id>
      <phase>generate-sources</phase>
      <goals>
        <goal>unpack</goal>
      </goals>
      <configuration>
        <artifactItems>
          <artifactItem>
            <groupId>org.dojotoolkit</groupId>
            <artifactId>dojo</artifactId>
            <version>${project.version}</version>
            <type>zip</type>
          </artifactItem>
        </artifactItems>
        <outputDirectory>${project.build.directory}/dojo</outputDirectory>
      </configuration>
    </execution>
  </executions>
</plugin>

Using Dojo in a WAR

<project xmlns="...">
  <modelVersion>4.0.0</modelVersion>
  <groupId>vom.acme</groupId>
  <artifactId>myproject</artifactId>
  <packaging>war</packaging>
  <build>
    <plugins>     
      <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-war-plugin</artifactId>
       <configuration>          
         <overlays>
            <overlay></overlay>
            <overlay>
              <groupId>org.dojotoolkit</groupId>
              <artifactId>dojo-war</artifactId>
              <excludes>
                <exclude>META-INF/**</exclude>
              </excludes>
            </overlay>
         </overlays>
       </configuration>
      </plugin>
    </plugins>
  </build>
  <dependencies>
    <dependency>
      <groupId>org.dojotoolkit.java</groupId>
      <artifactId>dojo</artifactId>
      <version>1.2-SNAPSHOT</version>
      <type>war</type>
      <scope>runtime</scope>
    </dependency>
  </dependencies>
</project>

Using Maven Repositories

<repositories>
  <repository>
    <id>dojo</id>
    <name>Dojo Maven2 Repository</name>
    <url>http://download.dojotoolkit.org/maven2</url>
    <releases>
      <enabled>true</enabled>
      <updatePolicy>daily</updatePolicy>
      <checksumPolicy>fail</checksumPolicy>
    </releases>
    <snapshots>
      <enabled>false</enabled>
    </snapshots>
    <layout>default</layout>
  </repository>
  <repository>
    <id>dojoSnapshots</id>
    <name>Dojo Maven2 Snapshot Repository</name>
    <url>http://download.dojotoolkit.org/maven2-snapshot</url>
    <releases>
      <enabled>false</enabled>
    </releases>
    <snapshots>
      <enabled>true</enabled>
      <updatePolicy>always</updatePolicy>
      <checksumPolicy>warn</checksumPolicy>
    </snapshots>
    <layout>default</layout>
  </repository>
</repositories>

Basic JavaScript Gotchas

Developing AJAX based applications, whether you use the Dojo Toolkit or develop everything the hard way from scratch, can pose quite a challenge to most developers. The difficulties typically arise from two main issues:

• JavaScript^(TM) is an interpreted language and is not compiled into machine code. Therefore, you do not have a compiler to catch common syntax errors.
• Various Web browsers report errors in different ways. For example, Mozilla Firefox^(TM) logs JavaScript errors into its JavaScript console. Microsoft^(TM) Internet Explorer might bring up an alert window with the line and error message.

This article presents common problems and how currently available tools might be used to debug them. This section is not intended as an all-encompassing debugging guide for JavaScript problems.

Debugging Issue 1: No Compiler Syntax Checking

Developers who have worked primarily with compiled languages will miss the compiler when working with a completely interpreted language like JavaScript. More often than not, the browser's error message is far from helpful in determining the actual root cause of the error. In addition, the errors reported by many AJAX toolkits are often not very helpful in determining the root cause of the error. For example, if you have written a custom widget based on the Dojo Toolkit that contains a syntax error and attempt to load it, you might get the following error:

FATAL exception raised: Could not load
'some.package.name.WidgetName'; last tried '__package__.js'

Unfortunately, the message does not tell you what the problem was, only that it could not load a particular widget. This error can be caused by many programming errors, but the most common ones are syntax errors in the widget JavaScript. The most common syntax errors that cause the above error are as follows:

• Using ';' instead of ',' when separating attributes of a JavaScript object definition.  This error is extremely common for novice JavaScript developers who have a background in Java or C++.

  Note: All Dojo Toolkit widgets and extension widgets are JavaScript objects and therefore any custom widgets must use the proper comma separator between properties of the object (these include function declarations as properties).

• Incorrectly terminating the last attribute definition in a JavaScript object definition with ','. The last property in any JavaScript object definition must never end with a comma.
• Malformed (unmatched) braces {} .
• Malformed function definitions.

You can avoid syntax errors by running a lint processor that understands JavaScript syntax on your code as you develop it. The lint processor will check for syntax errors before the code is run. Some of the JavaScript lint processors available on the web include:

• http://www.jslint.com/
• http://www.aptana.org/

Most lint processors are excellent at catching the errors mentioned previously and more. Many of the lint processors also enforce that JavaScript program statements always line terminate with ';' . While terminating with ';' is considered optional in JavaScript, it is highly recommended to do it for strictness and uniformity.

In summary, using lint syntax checking will save you hours of development time and frustration when trying to find the misplaced comma, malformed function, or missing closure.

Debugging Issue 2: Runtime Problems.

Assuming that all the syntactical errors were caught, by running a lint processor on the JavaScript code, and corrected the next set of problems are all related to runtime problems. These issues tend to be tricker to debug, as the various browsers do not report errors in the same way. Unfortunately, this means that, as a JavaScript developer, you must become familiar with debugging tools and browser error reporting mechanisms that are specific to each of the major supported browsers on which your application will be used. The list below outlines how some of the more well-known browsers report errors:

Microsoft Internet Explorer

Errors, such as accessing an undefined reference, are reported as a pop up from the browser with the line number and a simple description of what it believes the error is.

Mozilla 1.7.X and Firefox 1.5.X

The Mozilla and Firefox browsers report all JavaScript errors into a 'JavaScript Console'. So, often on a page that encountered JavaScript problems, the Web application just won't work and it's not always obvious why. So, while developing and testing using these browsers, you should regularly open and check the JavaScript console. This console can be located from the following menu locations:

• Mozilla 1.7.X: Tools->Web Development->JavaScript Console.
• Firefox 1.5.X: Tools->JavaScript Console.

The most common problems encountered at runtime tend to be:

• Referencing undefined variables. For example, trying to access an attribute on a currently undefined object, such as jsObject.someAttribute, where the jsObject variable has not been assigned.
• Functions defined on a JavaScript object accessing properties on that JavaScript object and failing to use the 'this' reference identifier. For example, the following is incorrect:
  /* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */ .geshifilter {font-family: monospace;} .geshifilter .imp {font-weight: bold; color: red;} .geshifilter .kw1 {color: #000066; font-weight: bold;} .geshifilter .kw2 {color: #003366; font-weight: bold;} .geshifilter .kw3 {color: #000066;} .geshifilter .co1 {color: #009900; font-style: italic;} .geshifilter .coMULTI {color: #009900; font-style: italic;} .geshifilter .es0 {color: #000099; font-weight: bold;} .geshifilter .br0 {color: #66cc66;} .geshifilter .st0 {color: #3366CC;} .geshifilter .nu0 {color: #CC0000;} .geshifilter .me1 {color: #006600;} .geshifilter .re0 {color: #0066FF;}
  function testOnload() {
         var fooObject = {
              fooAttribute: "This is foo",
              fooFunction: function() {
                  alert("The value of foo is: [" + fooAttribute + "]");
              }
          };
          fooObject.fooFunction();
      }   
  dojo.addOnLoad(testOnload);

  This is the correct way:

  /* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */ .geshifilter {font-family: monospace;} .geshifilter .imp {font-weight: bold; color: red;} .geshifilter .kw1 {color: #000066; font-weight: bold;} .geshifilter .kw2 {color: #003366; font-weight: bold;} .geshifilter .kw3 {color: #000066;} .geshifilter .co1 {color: #009900; font-style: italic;} .geshifilter .coMULTI {color: #009900; font-style: italic;} .geshifilter .es0 {color: #000099; font-weight: bold;} .geshifilter .br0 {color: #66cc66;} .geshifilter .st0 {color: #3366CC;} .geshifilter .nu0 {color: #CC0000;} .geshifilter .me1 {color: #006600;} .geshifilter .re0 {color: #0066FF;}
  function testOnload() {
         var fooObject = {
              fooAttribute: "This is foo",
              fooFunction: function() {
                  alert("The value of foo is: [" + this.fooAttribute + "]");
              }
          };
          fooObject.fooFunction();
      }   
  dojo.addOnLoad(testOnload);

Using JavaScript Debuggers

Debugging with the Dojo loader

The dojo.require() method of the Dojo loader uses a combination of XHR plus the eval statement to load JavaScript. This is one of the most powerful features in Dojo, however, it raises a few problems with some tools. First, most tools have no way to identify the source of the code. The information about the file or URL source of the buffer passed to eval in the Dojo loader is lost. (Note: the loader puts this metadata at the very bottom of the buffer, which may be inspected or parsed by some tools) Second, the Mozilla/Firefox console as well as most debuggers based on Mozilla's Spidermonkey engine suffer from a serious bug which makes debugging Dojo nearly impossible: all code loaded through an eval statement are identified at the location of the eval statement itself instead of the eval buffer. Not only are you presented with the wrong buffer for the stack frame, but the line number is also incorrect -- it is calculated as the offset of the eval command in the code plus the offset of the line within the eval buffer itself.

Neither Firebug nor Venkman work very well given the Spidermonkey limitation. Thankfully, there is an experimental patch available to Firebug which addresses both of these problems. Unitl then, setting debugAtAllCosts in djConfig can help better identify the error. Alternatively, you can [SCRIPT] include the JavaScript files directly on the page, but that can be very tedious.

Firefox Safe Mode

If you are having weird problems with Firefox, it is often worthwhile running Firefox in safe mode. This is because installed extensions can interfere with the DOM tree, CSS, or even with javascript. In Windows there is a shortcut to start Firefox in safe mode from within the Mozilla Firefox folder, from the Start button.

Javascript debugger statement

Javascript has a debugger keyword that forces a breakpoint to occur. Just insert debugger; and if you have a debugger for your browser, then it will stop at the debugger keyword.

This is especially useful when using Venkman, because otherwise it can be difficult to get Venkman into debugging mode (e.g. you try to click on a line of source and it puts in a [F] future breakpoint).

It also works with Firebug and most other JavaScript debuggers.

There's also a lint program which catches a variety of problems in source files, but also flags certain patterns which are valid JavaScript, but considered by the author to be bad style.

Profiling

Performance problems are bugs too, and Dojo has built-in facilities for identifying slow-running code segments. Some JavaScript debuggers like Firebug give file-loading performance, but often you need information at the code level.

You can cheaply calculate function execution time by taking the difference between two JavaScript dates. It's not a great technique, because you have to make educated guesses as to where the inefficient areas are, and it may take quite a lot of work to home in on the problem area. But it is easy to do if you are measuring a single function:

Another example of code to do this is on this page.

Alternative Host Environments: Adobe AIR

Introduction to Adobe AIR and Dojo

Adobe AIR is a new runtime by Adobe. Adobe AIR allows web applications permission to the local file system that traditional browser-based web applications do not normally receive due to security policies.

As of Dojo Toolkit 1.1.0 Beta 1, Dojo-based applications will now run successfully in Adobe AIR's secure application sandbox.

Getting Started

1. Download and install the Adobe AIR runtime and Adobe AIR SDK
2. Download the latest version of Dojo
3. Read the documentation below:

Modifications were required throughout the Dojo Toolkit to accommodate Adobe AIR's security policies for local web applications. Changes to Dojo were made in the following areas:

• dojo.require() pre-onload
• dojo.require() post-onload
• dojo.addOnLoad()
• dojo.query()
• dojo.parser
• dojo.fx
• Dijit widget system
• AIR dojox.storage provider

Creating the Development Environment

After installing the Adobe AIR runtime and the Adobe AIR SDK, you will find a bin directory inside the SDK containing the adl command used to execute an AIR application. By adding this bin folder to your path, you'll be able to execute the adl command from anywhere.

Start by creating an empty directory, and add Dojo to that directory.

Dojo's Package System

At the heart of the Dojo Toolkit is a package system that allows code to be loaded on demand. There are two loader mechanisms in Dojo: a default loader and a cross-domain (XDomain) loader. The default loader uses XmlHttpRequest (XHR) to retrieve the code. Once the code is downloaded, it is evaluated using eval(). This method is synchronous, so when a package is downloaded, its dependencies are also retrieved and executed. The XDomain loader uses script tags to retrieve dependencies, eliminating the need for evaluating the code after downloading. This method is asynchronous, so the XDomain loader has additional functionality for checking when the script has completely downloaded and to defer the declaration of the package until its dependencies have been loaded.

No debugAtAllCosts

Dojo has a configuration parameter called “debugAtAllCosts” which forces the use of the XDomain loader. This feature does not work properly with apps running on Adobe AIR. It is not required for developing Dojo applications, but needs to be disabled for applications to run on Adobe AIR.

dojo.require(): Using the default loader in the Adobe AIR Application Sandbox

Pre-onload

The default loader uses XHR to read in the contents of a package, then evaluates it. This functionality works as expected on Adobe AIR.

Post-onload

When the default loader gets the contents of a package, it evaluates the contents. Because eval() is prohibited post-onload in Aodbe AIR, dojo.require() cannot function post-onload. If dojo.require() is absolutely necessary post-onload, the XDomain loader is your only option. Otherwise simply define all your dojo.require()'s before or during onload which is analogous to other programming languages which require you to define all external code dependencies via an import/include at the beginning of the code file.

dojo.require() Using the default loader in the Adobe AIR Non-Application Sandbox

The default loader functions properly both pre-onload and post-onload.

dojo.require() Using the XDomain Loader

In order to use XDomain loader with apps running inside Adobe AIR, you must perform a custom build. Note the change that was required to make the XDomain loader work with Adobe AIR:

/* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */
.geshifilter {font-family: monospace;}
.geshifilter .imp {font-weight: bold; color: red;}
.geshifilter .kw1 {color: #000066; font-weight: bold;}
.geshifilter .kw2 {color: #003366; font-weight: bold;}
.geshifilter .kw3 {color: #000066;}
.geshifilter .co1 {color: #009900; font-style: italic;}
.geshifilter .coMULTI {color: #009900; font-style: italic;}
.geshifilter .es0 {color: #000099; font-weight: bold;}
.geshifilter .br0 {color: #66cc66;}
.geshifilter .st0 {color: #3366CC;}
.geshifilter .nu0 {color: #CC0000;}
.geshifilter .me1 {color: #006600;}
.geshifilter .re0 {color: #0066FF;}

Additionally, the _loadUri() function has to be modified to strip the app:/ protocol from the beginning of the URI since the app:/ protocol is unavailable in the non-application sandbox.

/* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */
.geshifilter {font-family: monospace;}
.geshifilter .imp {font-weight: bold; color: red;}
.geshifilter .kw1 {color: #000066; font-weight: bold;}
.geshifilter .kw2 {color: #003366; font-weight: bold;}
.geshifilter .kw3 {color: #000066;}
.geshifilter .co1 {color: #009900; font-style: italic;}
.geshifilter .coMULTI {color: #009900; font-style: italic;}
.geshifilter .es0 {color: #000099; font-weight: bold;}
.geshifilter .br0 {color: #66cc66;}
.geshifilter .st0 {color: #3366CC;}
.geshifilter .nu0 {color: #CC0000;}
.geshifilter .me1 {color: #006600;}
.geshifilter .re0 {color: #0066FF;}

Next you need to define a build profile which tells the build system which files to bundle in the build. We are not concerned with combining packages into a single file as much as we are in the XDomain loader and generation of .xd versions of each package. The difference in the .xd files is the package's contents are wrapped in a function call that allows the package's execution to be deferred until it's dependencies have been loaded.

A build profile may look like the following:

/* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */
.geshifilter {font-family: monospace;}
.geshifilter .imp {font-weight: bold; color: red;}
.geshifilter .kw1 {color: #000066; font-weight: bold;}
.geshifilter .kw2 {color: #003366; font-weight: bold;}
.geshifilter .kw3 {color: #000066;}
.geshifilter .co1 {color: #009900; font-style: italic;}
.geshifilter .coMULTI {color: #009900; font-style: italic;}
.geshifilter .es0 {color: #000099; font-weight: bold;}
.geshifilter .br0 {color: #66cc66;}
.geshifilter .st0 {color: #3366CC;}
.geshifilter .nu0 {color: #CC0000;}
.geshifilter .me1 {color: #006600;}
.geshifilter .re0 {color: #0066FF;}

To run the build, execute the following from the command line:

/* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */
.geshifilter {font-family: monospace;}
.geshifilter .imp {font-weight: bold; color: red;}
.geshifilter .kw1 {color: #b1b100;}
.geshifilter .kw3 {color: #000066;}
.geshifilter .es0 {color: #000099; font-weight: bold;}
.geshifilter .br0 {color: #66cc66;}
.geshifilter .st0 {color: #ff0000;}
.geshifilter .nu0 {color: #cc66cc;}
.geshifilter .re0 {color: #0000ff;}
.geshifilter .re1 {color: #0000ff;}
.geshifilter .re2 {color: #0000ff;}
.geshifilter .re3 {color: #808080; font-style: italic;}
.geshifilter .re4 {color: #0000ff;}

Now you can reference the build in your code by including the following:

/* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */
.geshifilter {font-family: monospace;}
.geshifilter .imp {font-weight: bold; color: red;}
.geshifilter .kw1 {color: #b1b100;}
.geshifilter .kw2 {color: #000000; font-weight: bold;}
.geshifilter .kw3 {color: #000066;}
.geshifilter .coMULTI {color: #808080; font-style: italic;}
.geshifilter .es0 {color: #000099; font-weight: bold;}
.geshifilter .br0 {color: #66cc66;}
.geshifilter .st0 {color: #ff0000;}
.geshifilter .nu0 {color: #cc66cc;}
.geshifilter .sc0 {color: #00bbdd;}
.geshifilter .sc1 {color: #ddbb00;}
.geshifilter .sc2 {color: #009900;}

dojo.require() will now work pre-onload and post-onload.

dojo.addOnLoad()

dojo.addOnLoad() registers callback functions to be executed when the page loads. The default loader properly executes the callback functions before the page's onload event is fired. The XDomain loader on the other hand fires the onload callbacks after the body's onload has fired. This causes problems for the XDomain loader in the application sandbox if parseOnLoad is enabled since Dojo will be unable to parse and eval() the data post-onload.

dojo.query()

Dojo has a query function that is used to search the DOM for nodes. The default query function works for simple queries such as “div” or “li > a”. However, the default query function is unable to find nodes based on a specific attribute. For example, the default query function is unable to locate the element /* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */
.html4strict .imp {font-weight: bold; color: red;}
.html4strict .kw1 {color: #b1b100;}
.html4strict .kw2 {color: #000000; font-weight: bold;}
.html4strict .kw3 {color: #000066;}
.html4strict .coMULTI {color: #808080; font-style: italic;}
.html4strict .es0 {color: #000099; font-weight: bold;}
.html4strict .br0 {color: #66cc66;}
.html4strict .st0 {color: #ff0000;}
.html4strict .nu0 {color: #cc66cc;}
.html4strict .sc0 {color: #00bbdd;}
.html4strict .sc1 {color: #ddbb00;}
.html4strict .sc2 {color: #009900;}
<button dojoType=”dijit.form.Button”>Click Me</button> using the
query “[dojoType]”. This was fixed by the following change to Dojo:

/* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */
.geshifilter {font-family: monospace;}
.geshifilter .imp {font-weight: bold; color: red;}
.geshifilter .kw1 {color: #000066; font-weight: bold;}
.geshifilter .kw2 {color: #003366; font-weight: bold;}
.geshifilter .kw3 {color: #000066;}
.geshifilter .co1 {color: #009900; font-style: italic;}
.geshifilter .coMULTI {color: #009900; font-style: italic;}
.geshifilter .es0 {color: #000099; font-weight: bold;}
.geshifilter .br0 {color: #66cc66;}
.geshifilter .st0 {color: #3366CC;}
.geshifilter .nu0 {color: #CC0000;}
.geshifilter .me1 {color: #006600;}
.geshifilter .re0 {color: #0066FF;}

dojo.fx

Dojo's FX library works as expected in both Adobe AIR's application and non-application sandboxes as well as with both the default and XDomain loaders.

dojo.parser

Dojo's parser scans the DOM using dojo.query() for declarative markup. If markup is found, it is evaluated. The parser can either be invoked automatically when the page loads or manually. The parser can be executed onload by specifying the following in the djConfig:

/* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */
.html4strict .imp {font-weight: bold; color: red;}
.html4strict .kw1 {color: #b1b100;}
.html4strict .kw2 {color: #000000; font-weight: bold;}
.html4strict .kw3 {color: #000066;}
.html4strict .coMULTI {color: #808080; font-style: italic;}
.html4strict .es0 {color: #000099; font-weight: bold;}
.html4strict .br0 {color: #66cc66;}
.html4strict .st0 {color: #ff0000;}
.html4strict .nu0 {color: #cc66cc;}
.html4strict .sc0 {color: #00bbdd;}
.html4strict .sc1 {color: #ddbb00;}
.html4strict .sc2 {color: #009900;}
<script type="text/javascript" src="path/to/dojo.js" djConfig="parseOnLoad:true" />

The parser will then scan the DOM for declarations such as:

<button id="myButton" dojoType="dijit.form.Button">Click me!>/button> 
<script type="text/javascript"< 
dojo.declare("tests.parser.SaySomething", null, { 
	sayWhat: "", 
	constructor: function(args, node){ dojo.mixin(this, args); }, 
	sayIt: function() { alert(this.sayWhat); } 
}); 
</script> 
<div dojoType="tests.parser.SaySomething" jsId="obj" sayWhat="Hello World!"> 
<script type="dojo/method" event="sayItReversed">
	alert(this.sayWhat.split("").reverse().join("")); 
</script> 
<script type="dojo/connect" event="sayIt"> 
	alert("sayIt() was called!"); 
</script> 
</div>

The parser works in both application and non-application sandboxes as well as with the default loader. When using the XDmain loader, the parser works as expected in the non-application sandbox. However, the XDomain loader fails in the application sandbox because the parser cannot
eval() post-onload inside Adobe AIR.

Dijit: The Dojo Widget System

Dijit widgets work both declaratively and programatically using the both the default loader in both application and non-application sandboxes. Dijit does not work properly with the XDomain loader since parser doesn't fire correctly.

AIR dojox.storage Providers

There are 3 new storage providers that leverage the AIR's API:

• dojox.storage.AirFileStorageProvider
• dojox.storage.AirDBStorageProvider
• dojox.storage.AirEncryptedLocalStorageProvider

When using the XDomain loader inside Adobe AIR, dojox.storage is unavailable until onload unless dojox.storage and the providers you wish to use are included in the XDomain build.

These 3 AIR specific storage providers are only available in the application sandbox. It would take a large amount of abstraction to each provider with respect to the AIR API calls plus a significant sized snippet of code in the parent window to perform the storage operation.

AirFileStorageProvider

The AirFileStorageProvider store the data in flat files in the app-storage directory. For example, a key of “MyKey”, value of “Hello World!”, and namespace of “MyNamespace” would create the file app-storage:/__DOJO_STORAGE/MyNamespace/MyKey which contains the text “Hello World!”. This storage provider allows for large amounts of data to be stored. Not only can strings be stored, but also objects thanks to AIR's serialize/de-serialize functionality. On the downside, data is not encrypted on disk. It would be trivial however to encrypt the information using dojox.crypto before storing the data.

AirDBStorageProvider

The AirDBStorageProvider leverages AIR's embedded database. When the provider is initialized, a database file is created in the app-storage directory and the Dojo storage table is created. The table holds the namespace, key, and value. This provider is similar to the AirFileStorageProvider in which it can store large amounts, but it cannot store serialized objects because there is no way to de-serialize them due to eval() being unavailable post-onload. The database file is not encrypted, but you could encrypted the data using dojo.crypto prior to storing the data. One advantage of the AirDBStorageProvider is there is only one file written to disk whereas the AirFileStorageProvider writes a file for each key/value.

AirEncryptedLocalStorageProvider

The AirEncryptedLocalStorageProvider uses AIR's encrypted local data store functions. Data, such as passwords, will be encrypted when being stored and decrypted when being retrieved. Similar to the AirEncryptedLocalStorageProvider, objects cannot be stored because they cannot be
de-serialized with an eval(). One limitation of the AIR's encrypted local data store is it does not provide a way to enumerate keys. To solve this, the AirEncryptedLocalStorageProvider creates a registry using AIR's encrypted local data store to track the namespaces and keys.

Default vs. XDomain Loader

The default loader cannot dojo.require() post-onload, however the XDomain loader can.
The XDomain loader requires a custom build, which in turn requires Java runtime environment installed. The default loader does not require a build, but would work if it was a custom build. If you are using the XDomain loader, unless the package you are requiring is already in the build, you cannot reliably access it until onload is fired.

There may be caching issues with the Xdomain loader pulling in code that not already in the build on subsequent requests, which causes out of order execution of code before dependencies have loaded. It is recommended to bundle all needed packages into the XDomain build. The XDomain loader fires dojo.addOnLoad() callbacks after onload which causes Dojo's parser in the application sandbox to fail because it cannot eval() post onload inside Adobe AIR.

Application vs. Non-Application Sandbox

The non-application sandbox does not recognize the app-storage:/ and app:/ protocols. Due to the lack of eval() post-onload, the XDomain loader doesn't work in the application sandbox when the parser is used.

application.xml

Here is an example of an application.xml file for a Dojo-based web application:

/* GeSHi (C) 2004 - 2007 Nigel McNie (http://qbnz.com/highlighter) */
.geshifilter {font-family: monospace;}
.geshifil