In most cases each application has its own set of specific resources, e. g. images, flash movies, CSS stylesheets and so on. This document explains how to use some advanced features of the qooxdoo build system for your application.

Let’s begin with the definition of an alias to the path where you have stored your resource files. In your application class this is done easily. You just have to define an initialize method which registers this alias at the AliasManager API.

qx.Proto.initialize = function(e) {
  qx.manager.object.AliasManager.getInstance().add("custom", "./resource");
};

In this case ./resource refers to a real path. This could also be a more complex path or even an URL to another server e.g. http://myserver/data/resources.

But rather than using literal paths in your application, it is best to make the resource folder available through a setting:

qx.Settings.setDefault("resourceUri", "./resource");

Afterwards you can register your resource in a similar way using the defined setting:

qx.manager.object.AliasManager.getInstance().add("custom", \
  qx.Settings.getValueOfClass("custom.Application", "resourceUri"));

This makes it possible to change the resource folder without scanning for all occurences of the path literal. (This feature is also used by the qooxdoo skeleton in the SDK release).

The AliasManager takes care of path aliases in path specifications. After registering this alias you could simply use it to access your images:

var myImage = new qx.ui.basic.Image("custom/sample.gif");

instead of the alternative:

var myImage = new qx.ui.basic.Image("./resource/sample.gif");

On the one hand this is especially interesting for long original paths (to shorten them). On the other hand it is possible to change the real location of such stuff, without changing your code. A simple redefinition within the “initialize” function is all what it takes.

After you have done this, the source version of your application should already work well. Now let’s continue with the build version...

The idea behind the build version is to produce an application that is completely self-contained. This means that the images (and other resources) from the source folder have to be copied to the build folder.

If you don’t want to do this by hand you can take advantage of qooxdoo’s build tools.

If you do not use a skeleton-based environment, you might want to use the generator.py to do selective copying for you. See copying_resources for more information on the generator and its options in this regard.

The generator script will only copy things which are required by one of the included classes. To make this possible, you need to add a hint to your source code, to indicate which class uses resources from a specific folder. You can do this by adding something like

/*
#resource(key:folder)
*/

to your class file. The key is an indentifier which could be used to transfer the content of the defined folder to a target directory other than the default one. Just use something identical and ignore it for the moment. The folder is a directory which has to reside whithin the path specified with the --resource-input parameter to generator.py.

Once the class is included in the build, either by explicit inclusion or by dynamic dependency resolution, the required resources are copied on demand. As a result your build only incorporates a minimal set of required resources.