Download 1.5.x - Docs

qooxdoo Documentation, Release 1.5.1
each file individually, read its code and comments, set breakpoints, inspect variables and so forth. You only have to
re-run the generator 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.
For the source build there are two variants which you might find interesting. One is called source-all and will
include all the known classes, 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 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 even slower in the browser, so it’s a trade-off between development speed and loading speed.
Another variant, source-hybrid, addresses the loading speed of the source version. It does not load all classes
from the original source path, but concatenates their contents into a few files, only leaving your own application classes
untouched. Now you get the loading speed of nearly the build version, but can inspect and debug your own class files
as before. Best of both worlds, so to speak. 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 “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 plain “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
generate.py build
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 come along, 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
http://fooserv/~bar/myapp/
Non-App-Generating Jobs
So now you know about the basic jobs to create a runnable application using the generator. There is a whole bunch of
jobs that is not concerned with creating a runnable version of your app, but do other things. One of those is addressed
in the Twitter tutorial which is concerned with internationalization of an application. The generator job in this context
is translation, and extracts translatable strings from your JavaScript source files into .po files. Here is a quick
topical overview of those kinds of jobs:
Internationalization:
• translation – extract translatable strings into .po files
Source Code:
52
Chapter 2. Getting Started