Skip navigation

Tag Archives: javascript

These instructions will walk you through how to use Google Closure Templates with your own closure set up, using goog.require and goog.provide.

First make sure you know how to use goog.require and goog.provide for your own code.

Secondly, read the instructions for using Google Closure Template with JavaScript.

The easiest way to get all of this to work nicely is to use a directory structure such as this:


Explaining these directories:

Where all of your JavaScript files are, your path to this place is probably different.

Where the Google Closure Library source code lives (closure-library-read-only/closure/goog/).

Where your application’s code is.

Where you’ll have the Google Closure Template generator put your compiled template (JavaScript) files.

Where you need to put Google Closure Template’s JavaScript files. Otherwise you’ll get this error:

Exception: Missing provider for (soy)

Where you’ll put your .soy files.

When you generate your template files use the –shouldProvideRequireSoyNamespaces parameter to make sure you add the correct goog.provide and goog.require statements.

When you call the template compiler be sure to make sure it’s putting them into the right place (/media/js/app/templates).

Make sure the namespaces you use in your templates adhere to the directory structure you’re using so that goog.provide and goog.require work correctly. For example:

For a template called “” (/media/templates/ use


as your namespace. This file should create a “hello_world.js” by the generator (/media/js/app/templates/hello_world.js).

In your require.js (/media/js/app/require.js) add


and you should be good to go.

Make sure you give the path to /media/js/soy to the Google Closure Compiler (not the template compiler, when you’re compiling your actual JavaScript app) when you generate your deps.js or release with the -p option.

You can view the character codes for the ASCII table on any unix or linux system easily by simply looking in the man.
On any command line type:

man ascii

voila! Before I figured this out I had always looked online and found only crappy ad spamming websites that uses images for ASCII tables so you can’t select or copy the values. As a JavaScript programmer I haven’t been all that aware of the power of my Mac OS X’s unix engine provides.

Posted via email from Apphacker’s learning curve

Squiggly is Adobe’s Spell Checking software for Flex and Flash applications, and it just so happens that you can use the spell check engine in AJAX Adobe AIR applications. That is if anyone out there except for me is using AJAX to make AIR Applications. Sometimes I wonder, you know.

Anyway, you obviously can’t use the Flex UI controls in your HTML and JavaScript AJAX applications, but you can use the spell check engine.

These are the general set up steps:

  1. Download the Squiggly package.
  2. Rename the SpellCheckEngine.swc to use the .zip extension and unzip it.
  3. Recover the library.swf from the package and put it in your application (maybe rename it too).
  4. Add a script tag for the library.swf resource obtained from the SpellCheckEngine as outlined in these instructions.
  5. From the Squiggly packaged find the ‘usa.zwl’ dictionary file in the Dictionary directory and place that in your application source code.

Now you should be able to use the library:

        var sp = new );
        var dict = new );
        var myUrl = new air.URLRequest( 'usa.zwl' );
        // the constant is air.Event.COMPLETE if you have AIRAliases.js included
        dict.addEventListener(, function( event ) {
          var addSuccessful = sp.addDictionary( dict );
          // log this return value to test it
          console.log("Added dict: " + addSuccessful);
          console.log("isLoaded on complete" + dict.loaded);

          console.log(  sp.checkWord( "test" ) ); //Prints  'true'
          console.log(  sp.checkWord( "testzd" ) ); //Prints 'false'

        dict.load( myUrl );
        sp.addDictionary( dict );

Check out the example code included in the Squiggly package for how to get suggestions. If you want a nice UI for rich text editing think about using a div with contentEditable set to true.

Thanks goes to the Adobe Forum for Squiggly for being so responsive and helpful. If you have any questions that’s the place to go, although not many people are using it with JavaScript.


Using goog.require and goog.provide for your own JavaScript packages and modules will not automatically work. You have to use goog.addDependency, and this is best done using a provided python script which will help you create a dependency file.

Added a HOWTO for using Google Closure’s Template files with your own code.

The difference between dojo.require and goog.require
(skip if you don’t care about Dojo)

Coming from the world of Dojo to the Google Closure Library I thought I could use goog.require and goog.provide the way I am used to with Dojo. Nope, it’s done differently.

The big difference obviously is that with Dojo, dojo.require is magic and happens automatically. Dojo will use an XMLHttpRequest to evaluate your JavaScript on the fly. Google’s system works differently, it creates script tags. Google’s system is better for debugging. Dojo provides some options for also using script tags but because that’s not the intended means of using dojo.require it can lead to problems.

Using script tags makes debugging easier because in debugging tools (such as Firebug, IE’s Developer Tools, or Webkit’s Web Inspector) JavaScript provided with script tags can be located by filename. How evaluated code shows up in debugging tools depends on the tool but it’s never simple or easy and becomes worse the more JavaScript you’ve evaluated.

Another difference is that goog.require doesn’t request your code if it doesn’t already know where to find it. You tell Closure where to find it by using goog.addDependency, an extra step not required in Dojo. The best way to do this is to use a python script included with the framework.

With Dojo you could dump your dojo.require wherever you wanted, similar to use of #include in C source files. You don’t want to do this with the Google Closure Library as the code is added via a script tag and wont be available until that script tag has been added. Instead create a single place where all your goog.require statements are, probably a separate JavaScript file or in a separate script tag in your markup.

There’s also a difference between Dojo’s custom builds and the Google Closure Compiler. Google Closure Compiler is a separate tool but the best means to use this tool if you’re already using the Google Closure Library is to use the provided python script.

Having explained the differences there are also similarities: directory structure is just as important when using goog.require as it is with dojo.require. If your goog.provide is “myapp.subapp.view” you should have a directory structure as you would for dojo (more below).

The three options

Before I explain the means by which you can use goog.require and goog.provide for your own code you need to know about the three options available when you use the python script provided by the framework:

  • deps – generate a dependance file – If you use this option, when your site is loaded in the browser many script tags are added, one for each file.
  • script – generates a single JavaScript file that includes all of your code and parts of the goog namespace you’re using. You will only have one script tag, but your JavaScript will be otherwise unchanged.
  • compiled – generates a single compiled JavaScript file that includes everything you need. Requires Google Closure Compiler’s compile.jar (available separately). You will only have one script tag of minified JavaScript. Your code will be significantly modified, the degree to which depend on the compiler flags provided.

Most of the details of these three main options (there’s also a list option useful for information purposes only) can be read about on the documentation page for the script. What the docs are not clear about is how to point the script to your code. I will explain this to save you a period of trial and error and also show an example.

Initial setup

In this set up I keep goog and my Javascript separate. I don’t like including big external libraries in my source control and Google Closure Library is over 100MB! I used to include JavaScript libraries but as they’ve grown in size and complexity I’ve decided to stop doing this, similar to external python libraries. This is handy if you like to create a lot of releases and branches and don’t want to take up hundreds of megabytes of hard drive space on your subversion server for every branch and release.

My directory structure is as such where / is web root (not / on the computer):


/media/js/goog/ is a symlink to what in the Google Closure docs would be described as closure-library-read-only/closure/goog/. This is on my dev machine where I have the Google Closure library. I don’t have the Google Closure Library on the production machine because when I create a build I don’t need it.

/media/js/myapp/ are the checked in files for my JavaScript app. It is the root for my application.

/meda/js/release/ is where my compiled JavaScript files are, I’ll only use this in production.

Let’s say I have a sub application with two files:


At the top of the file in in /media/js/myapp/subapp/controller.js I will put:

goog.provide( "myapp.subapp.controller" ); 

and in the other file I’ll put:

goog.provide( "myapp.subapp.view" ); 

Whatever code these files have go below these lines.

Next I create a file that will have all my goog.require statements:


The contents of this file will be:

goog.require( "" );
goog.require( "goog.dom" );
goog.require( "myapp.subapp.controller" );
goog.require( "myapp.subapp.view" );

I have added require statements for goog.dom and because I will be using those parts of Google Closure Library in my own code.

What is in my index.html file varies depending on if I am using it for development or production. In development I’ll have:

<script type="text/javascript" src="/media/js/goog/base.js"></script>
<script type="text/javascript" src="/media/js/myapp/deps.js"></script>
<script type="text/javascript" src="/media/js/myapp/require.js"></script>

Note the deps.js, this is a generated file. In production I’ll simply have:

<script type="text/javascript" src="/media/js/release/subapp-compiled.js"></script>

I create different files for every subapp because each subapp in my architecture exists on a separate page. This might be different for you. This would require a different require.js for every subapp, and during compilation additional compilations for every compiled file.

Using to create a dependency file

This section explains how to use the script included in the Google Closure Library. I recommend reading the documentation carefully. Even so, what I describe below, with regard to the difference between creating a dependency file and a compiled file and the paths is not included in the documentation.

IMPORTANT: On your development machine find your way to your /media/js/myapp directory. You will want to be here when you call the script. If you are in any other directory this will fail because of how the script works. There is a CLOSURE_BASE_PATH variable you can set in your JavaScript that can help with any errors you might run into if you do this differently.

I call the as such (closure-library-read-only is the path to Google Closure Library on your system):

closure-library-read-only/closure/bin/ -i ./require.js -p .. -o deps > deps.js

This created:

// This file was autogenerated by
goog.addDependency('../utils.js', [], []);
goog.addDependency('../myapp/deps.js', [], []);
goog.addDependency('../myapp/require.js', [], ['', 'goog.dom', 'myapp subapp.controller', 'myapp subapp.view']);
goog.addDependency('../myapp/subapp/controller.js', ['myapp.subapp.controller'], []);
goog.addDependency('../myapp/subapp/model.js', ['myapp.subapp.Model'], []);
goog.addDependency('../myapp/subapp/view.js', ['myapp.subapp.view'], []);

Couple of things of note:

Notice utils.js and model.js. I didn’t talk about these files or add them to require.js because I’m not using them but look the script found them anyway. uses the path given via -p option and traveres all its subdirectories recursively looking for files. It searches the files for goog.require and goog.provide statements and uses those to calculate what goog.addDependency statements it needs to create.

The first argument to goog.addDepedency is the file name, the second is the goog.provide statements found in the file, and the third is the goog.require statements in the file.

The .. path is relative to /media/js/goog/base.js. Very important.

If you now request index.html and look in Firebug’s net tab you’ll see requests for all of the necessary dependencies for and goog.dom, as well as


You wont see:


because you haven’t requested them with goog.require. You can simply add another goog.require statement for /media/js/myapp/subapp/model.js to /media/js/myapp/require.js without calling again and it will request the file! utils.js doesn’t provide a goog.provide statement so you have to create a separate script tag for it.

Using to create a compiled file

Remember: You need to download compile.jar separately, it’s not included in the library!

For the purpose of creating a dependency file we used relative paths which created relative paths in your deps.js file. For creating a compiled file we will use absolute paths and we have to add the path to the Google Closure Library in addition to the path to our own code.

I changed my current working directory to /media/js/release and call this in my terminal:

closure-library-read-only/closure/bin/ -i /Users/Bjorn/projects/site/media/js/myapp/require.js -p closure-library-read-only/ -p /Users/Bjorn/projects/site/media/js/myapp/ -c /Users/Bjorn/closure/compiler/compiler.jar -o compiled > subapp-compiled.js

/Users/Bjorn/projects/site is where my website is in my file system.
closure-library-read-only is wherever your copy of the ENTIRE Google Closure Library is on your system, not just the JavaScript.
/Users/Bjorn/closure/compiler/compiler.jar is where I have put the compiler.jar file for the purpose of this example on my file system.

Running this statement creates:


This is a JavaScript files that has all the code I need to run subapp. If I later want to include myapp.subapp.model I have to rerun the statement. That’s why it’s better to use a dependency script for dev and compiled file for production. You don’t want to have to compile your code every time you edit your files during development and debugging obfuscated code created by compilation wont be fun. In production however you don’t need to do any of this and having one file reduces page load times for users.

In conclusion
I hope this has helped you figure out how to use goog.require and goog.provide for your own JavaScript code. I recommend also looking at the compilation flag options and reading the rest of the documentation.

So I’m pretty unhappy with the existing unit test frameworks out there for JavaScript. There’s Dojo’s D.O.H., YUI Test ( written by @slicknet ), JSTest, JSUnit, Jquery’s QUnit.

And now there’s Achaean.

Summary of the project:

No assumptions. One file. Easy to use.

There are many JavaScript? unit test frameworks out there. More notably Dojo’s D.O.H., JSUnit, JSTest, YUI Test. If you search Google Code’s project hosting, you’ll find even more. They all assume a lot. They may assume you’re testing in a browser or Rhino. They may assume you’re using a given framework. They may require several files, a custom build, or something else.

This framework will require nothing other than one file. You can test in a browser or on the command line using Rhino, this framework is agnostic on the issue.

How does it work? The result is a native JavaScript? object that is returned to the script running the test. You can do whatever you want with it. It will have a list of errors, test results, in plain text, or html. You can display it in the browser console, on a Rhino Shell, in an HTML document, an XUL Panel , or even an alert window and format it as you want.

Achaean’s flexibility will let you use it as part of a build script to ensure required tests pass before building or packaging for production or staging.

Ease of use.

Simple methods, simple set up. Just download the file, look at the few simple steps involved and start writing your tests within minutes.

Here’s the code. Feedback welcomed.

I have made my Adobe AIR IRC client Diomedes IRC open source, utilizing the MIT license. :)

Check out the project page for more info.

Diomedes IRC

This is kind of fun. I got my Diomedes Adobe AIR IRC client made with JavaScript listed on the official Adobe AIR Market Place. It’s been up all day and only two downloads though, one from someone I know. :(

It is kind of fun making stuff and putting it up. Would be nicer if someone actually used it. :o

Next I’m going to work on a game, possibly using canvas. Looks like that will be a lot of work since drawing on a canvas is really low level drawing basic shapes and lines. Animation consists of clearing and redrawing the canvas. Yeah.

I haven’t blogged about it yet, but I’ve been working on an IRC client in Adobe AIR using Javascript, AJAX and HTML/CSS.

I’m going to make a more recent download available soon at The version that’s available now on that site is very old and buggy. I don’t recommend using it!

Here are a couple of screen shots of latest progress:

Diomedes IRC

Diomedes IRC

Dojo’s stopEvent method is a crossbrowser compatible way to stop further event bubbling when you want to take charge and control what happens manually. For example if you add an onclick event to an anchor and don’t want the browser to go the page specified in the elements href attribute, you can use the stopEvent method to prevent it from happening. You can also prevent also other many things, including button submits and the checking or unchecking of checkboxes. However, there’s a bug here! If you do use stopEvent to stop a checkbox toggle, you can’t set it manually either! Copy and paste this code and save it in an .html file and then open it up in a browser to see for yourself (the script tag points to a version of dojo hosted by Google):

<SCRIPT TYPE="text/javascript" SRC=""></SCRIPT>
<title>Script checkbox test thingy</title>
<h1>Check this box</h1>
<div id="container">
<input type="checkbox" id="cb" />
<label for="cb">Check it</label>
<script type="text/javascript">
dojo.byId("cb").checked = true;

There is a solution however! Use setTimeout with a wait time of 0 to attempt to check the box, and it will work!

window.setTimeout(function(){ dojo.byId("cb").checked = true;},0);