Tutorial: Basic Tool Chain Usage¶
In various introductions and tutorials you were using the qooxdoo tool chain casually along the way. Now it's about time to take a more systematical look. The main interface to invoke the tool chain is the generate.py script that is part of every skeleton, often colloquially referred to as "the Generator". In each qooxdoo library or application, it sits next to the library's Manifest.json and the default configuration file, config.json. The Manifest.json file is the main declaration file for any qooxdoo app, it's constitutional document if you will. config.json is the configuration file that steers the Generator and its actions. When invoked, the Generator looks for a file of this name in the current directory for default instructions, but you can supply an alternative configuration file with a command line option. Invoking
generate.py -h |--help
gives you a complete list of those options.
In the general case the Generator takes the name of a job to perform as its sole argument. You can even invoke it without any argument, and it will run the "default job" if the configuration defines one.
Supplying a non-existing job name will result in the Generator providing a list of known jobs which it can perform. You can try this by using a made-up job name like "x":
The ensuing list can be daunting at first, but we will pick out the most important jobs here.
Generating a Runnable App¶
Use the Source, Luke¶
The tool chain is able to generate your application in various flavors. This is reflected by the available generation jobs, "source", "source-hybrid", "source-all" and "build". The most important for starting and building up your app, are the source jobs. Running
will generate the so-called "source version" of your application in the default variant.
In general, the source version of an app is tailored towards development activities. It makes it easy to write code, run the application, test, debug and inspect the application code, fix issues, add enhancements, and repeat.
You only have to re-run this Generator job when you introduce new dependencies, e.g. by instantiating a class you haven't used before. This changes the set of necessary classes for your application, and the Generator has to re-create the corresponding loader.
In the source-hybrid version, the Generator will concatenate class files into a bunch of script files, except for your application classes which are loaded directly from their original path on the file system. This allows for a reasonable loading speed of your application in the browser while still providing convenient debug access to your own class files.
With source-all all existing classes will be included, be they part of your application, the qooxdoo framework, or any other qooxdoo library or contribution you might be using. All those classes are included in the build, whether they are currently required or not. This allows you develop your code even more freely as you don't have to re-generate the application when introducing new dependencies. All classes are already there, after all. The down-side is that due to the number of classes your app loads slower in the browser, so it's a trade-off between development speed and loading speed.
So if you are just getting started with qooxdoo development, use the source-all version, which is the most convenient if you are not too impatient. If you are concerned about loading speed during development, but don't mind hitting the up and return keys in your shell window once in a while, go with the default source-hybrid job. If your emphasis on the other hand is on inspection, and you want to see exactly which class files get loaded into your app and which code they provide, the source version might be your preference.
A Deployment Build¶
On the other end of the spectrum there is the build version of you app. The "build" version is what you want to create at the end of a development cycle, when your app is stable and you want to deploy it into production. Running
will create a highly optimized version of your app. All necessary code is stripped, squeezed and compressed, and put into as few JS files as possible. Everything is geared towards small size, fast transport, fast loading and minimal memory footprint. Along with the code, all other required resources, such as icons and images, are collected together under a common root directory, usually named build. The good thing here is that this makes the contents of this directory self-contained so you can copy it to the document tree of a web server, zip it up and send it by mail, and so forth. All necessary content will be included, and the app will just run when the contained index.hmtl is loaded.
For an example let's suppose you have an application myapp and a web server instance running on a machine called fooserv. Then, given suitable network connection and setup, the following command will copy your build version to the web server:
scp -r build bar@fooserv:~/public_html/myapp
and you can load it in the browser with
- translation -- extract translatable strings into .po files
- lint -- check source code for potential issues
- fix -- fix white space in source code
- pretty -- re-format source code
- api -- create an application-specific instance of the Apiviewer
- test -- create an application-specific instance of the Testrunner
- clean -- clean up generated files for this app
- distclean -- clean up generated files for this app, and delete the Generator cache
As mentioned before, for a full list of available jobs with short descriptions run generate.py x, or see the the list of default jobs.
For most people the jobs that come with qooxdoo are good enough to get all necessary work done. But not for all. Sometimes you want the output file be named differently; or the index.html that loads your qooxdoo app lives in some other part of your web space; or you want to get rid of a specific optimization in your build version. Fortunately, the tool chain of qooxdoo is very flexible and highly configurable. There is a set of built-in functionality that can be drawn upon by job definitions, and jobs can be freely defined or altered. The system is in fact so configurable that we have thought of means of limiting its flexibility, for the sake of an easier user interface. If you feel you want to change the way in which a particular Generator job works, or define one from scratch, see a dedicated page on this topic.