How can I load my own js module with goog.provide and goog.require?_问答_开发者

We are trying to switch the packaging for our project from dojo to google closure, but we haven't had any luck so far. Here is a simple example that illustrates what we are trying to accomplish:


<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <script type="text/javascript" src="开发者_Go百科runtime/src/core/lib/goog-rev26/base.js"></script>
        <script>
            goog.require("foo.bar");
            function main() {foo.bar.echo("hello world")}
        </script>
    </head>
<body onload="main()">
</body>
</html>

Then in /foo/bar.js I have:


goog.provide("foo.bar");
foo.bar.echo = function(s) {console.debug(s);}

The errors I receive in firebug are as follows:

goog.require could not find: foo.bar
foo is not defined

When I look in the Net tab, there isn't an http request out to fetch a file - I was expecting the closure library to generate a script tag to fetch bar.js.

help! ;)

I figured it out and it's not very hard, but there are a few gotchas.

Basically, you can use the dependency generating script calcdeps.py (you should read calcdeps.py docs) in one of several modes:

Generating deps.js file
Concatenating everything into a single file, optionally compiling it using the closure compiler.

For development you should use (1), since it allows you to not run the calcdeps.py after editing the JS sources, unless you make changes to the dependency tree. The rest of the answer is about this way, I haven't tried the other one yet.

Here's what I did to generate it:

#!/bin/bash
cd closure-library/closure/goog
python ../bin/calcdeps.py -p ../../../js -o deps > ../../../my-deps.js

...assuming the following directory structure:

project/
  closure-library/ (as checked out from SVN)
  js/ (my JS code)
  app.html

(the -p parameter traverses all js files in the specified directory and the docs say you can specify multiple directories to search if you have to.)

The above call creates a my-deps.js file next to the main app.html, which I use to run the application. The created file contains information about my JS files in js/ and looks like this:

goog.addDependency('../../../js/controllers.js', ['proj.controllers'], []);
goog.addDependency('../../../js/ui.js', ['proj.ui'], ['proj.controllers']);

- where the first string it the path to my JS file relative to closure-library/closure/goog/base.js (this is important!), the second array is the list of goog.provide-d strings, and the last array is the list of goog.require-d strings.

Now in app.html I have:

<script src="closure-library/closure/goog/base.js"></script>
<script src="my-deps.js"></script>
<script>
  goog.require("proj.ui");
</script>
<script>
  // here we can use the required objects
</script>

Note:

In addition to including closure's base.js, I include my generated deps.js
As mentioned in the tutorial the goog.require call has to be in a separate script tag, because it appends a script tag to load the required scripts and they are loaded after the current script tag finished processing.

Gotchas:

The described above issue with paths being relative to base.js. goog.require creates the script URL to load by concatenating the base.js base URL (i.e. without base.js leafname) and the first parameter to goog.addDependency in deps.js.
calcdeps.py doesn't work well on Windows, in particular using the backslashes in the deps.js string literals
If something doesn't work well, you may want to look through all issues mentioning calcdeps and make sure you have an up to date checkout.

Update!!!

New version of calcdeps.py changes the game a little bit. To create your deps.js you now need to use the -d flag. eg:

python path-to-closure-library/closure/bin/calcdeps.py -i path-to-your-src/requirements.js -o deps -d path-to-closure-library/closure/ -p path-to-your-src/ --output_file=path-to-your-src/deps.js

To compile:

python path-to-closure-library/closure/bin/calcdeps.py -i path-to-your-src/requirements.js -d path-to-closure-library/closure/ -p ./ --output_file=path-to-your-release/scripts.min.js -c path-to-compiler/compiler.jar -f "--compilation_level=ADVANCED_OPTIMIZATIONS" -f "--debug=true" -f "--process_closure_primitives=true" -f "--manage_closure_dependencies=true" -o compiled

So the process is actually now a lot easier, but you have to use your powers of ESP to find out about it as its totally undocumented. The calcdeps.py now also does not work with Python 3.1 on windows so that is also heaps of fun. A few hacks got it working for me (which I will not put here as I'm not a python programmer and there must be better ways to do it).

Generally the last day has been super fun, hope this post helps someone avoid the same enjoyment.

Guido

I was able to get it to work by adding the following to deps.js:
goog.addDependency('../../../foo/bar.js', ['foo.bar'], []);

Firefox now makes an http request to /foo/bar.js when it encounters the goog.requires statement.

However, the file contains this comment:
// This file has been auto-generated by GenJsDeps, please do not edit.

According to this, GenJsDeps is the same as calcdeps.py. If you look at the documentation, it looks like there is an -o deps switch which will re-generate deps.js so it isn't edited manually.

Yes you should use calcdepds.py. I created a big blog post after much trial and error to figure out the best way to do this, I also go over the differences between dojo.require and goog.require:

http://apphacker.wordpress.com/2009/12/28/howto-how-to-use-goog-require-and-goog-provide-for-your-own-code/

Here's a little project that I've been working on that might be helpful to you: http://github.com/fintler/lanyard

Take a look at the build.xml, the file named lanyard.js, and all of the files located in src/geom/*.

The build.xml has an example of how to call calcdeps.py through ant for all of the js located in src. It may not be the best way to do things, but it's been working for me so far.

Either way to get custom modules working, at least for development version, is to include manually js files in head section of html page, after google's base.js file inclusion.

<script type="text/javascript" src="js/closure/goog/base.js"></script>
<script type="text/javascript" src="js/closure/custom/custom.js"></script>
<script type="text/javascript" src="js/closure/custom/sub/sub.js"></script>
...

But, you should care about sequence of inclusion by yourself. For not very large custom files sets it works good. For production version you still had better use js source compiling to get all benefits of closure library.

solution:

download closure to your project externals (or assets, whatever).
don't bother with setting onload, delay, playing with async, etc..
they won't work (they are also very poor design pattern and extremely lame..)

- this is your `main.js` where you dynamically injecting your code into the DOM (for example creating a bookmarklet or something):

/**
 * loads the base.js of google closure.
 * http://code.google.com/p/closure-library/
 */

(function() {
  var s = document.createElement('script');
  s.type = "text/javascript";
  s.src = "./assets/closure/goog/base.js";
  s.async = true;
  document.getElementsByTagName("body")[0].appendChild(s);
}());

/**
 * activated from the base.js as JSONProtocol.
 */
window['starter'] = function() {
  console.log("hi...");
};

now:

edit your base.js

add the the end of the file

......
.......
........

/**
 * run the method when done load. just like JSONProtocol.
 */
window.setTimeout(function() {
  window['starter']();
}, 5);

your "callback" simply activates starter when the file has done rendering,
it works perfectly and it keeps loading every resource asynchronously.

p.s.

the window['....'] syntax is so you could safely use closure-compiler to the max and always use the same name (although there are another ways to do so, but this is the simple "always working" way..).

2. on `base.js` you could also avoid the timeout and just use

......
.......
........

/**
 * run the method when done load. just like JSONProtocol.
 */
window['starter']();

but as a rule of thumb modern browsers acts better when you wrap those "don't care, just do this stuff at the end, like JSONProtocol callback" stuff-

timeouts (mostly used with values from 0-5) are not interrupted as timeouts but as a way to breaks the synchronicity of the code-block allowing truly "context-switch"-like behavior.

although there is an extra overhead there.