There was another workshop at the Webinale 2008 in Karlsruhe, Germany hold by me: Web Application Development with qooxdoo. The intention was to show the needs and possibilities to solve enterprise needs in web application development. This was done using the qooxdoo tool chain.

The workshop went quite good. Some people did the stuff practically during the workshop with great success. Others just followed the presentation theoretically.

For all of you who want to try it on your own, I have uploaded the workshop material to our server. The downloadable archive (about 12 MB) contains a prepared qooxdoo distribution (contains the API viewer, the framework sources and the tool chain).

Inside the archive you can find a folder Snapshots which contains three interesting folders:

• app1: Feed Reader
• app2: Feed Reader with usage of parts (only for build target)
• app3: Feed Reader with usage of browser variants (only for build target)

Please have a look at the file config.json for the configuration data of the build system. This really might to be a good chance to all of you who want to learn the new generator features practically in a safe, prepared environment.

In each folder you can find a shell script and a batch file to execute the new generator (generator II). You should be able to execute all offered jobs (source, build, api and clean). For the batch files you need to have a Python installation under C:\Python25. Please install Python natively under this path (This is the default path for the Python installer). There is no need for Cygwin when using these batch files.

| View | Upload your own

In one of the last sessions of the Dynamic Languages World I did a talk about JavaScript tooling. My objective was to give a general overview over some current JavaScript tools.

I covered JavaScript linker, tools to generate API documentation, lint tools and JavaScript packer.

| View | Upload your own

You can download the demo application used in the presentation. I have included a stripped down qooxdoo version so you can just download and run it.

The generator, heart of qooxdoo's tool chain, has been overhauled extensively for 0.8, close to a complete rewrite. Main objectives for the new implementation include

• support for parts
• run multiple jobs "in one go"
• replace "make" and other GNU/Unix tools as far as possible, to cut down on prerequisites
• support a unified application/library structure throughout the project
• pave the way for an enhanced GUI-based build tool

The first and maybe most visible change the new generator brings for the users is the changed configuration. The current tool chain relies heavily on GNU's make, deploying various related Makefiles. The primary means to configure the build process is through Makefile variables. The new generator replaces these make tools with config files that are based on JSON, a data format that blends well with both Javascript and Python.

The challenge here was to use JSON's basic declarative syntax elements like dictionaries (maps), arrays and simple data types, and build upon them a semantics that is both rich, to provide a sufficient level of power and abstraction, and generic, to cover all necessary use cases. (It almost feels like defining a new XML schema...).

The current state of the issue is that a config file contains a single big map that keeps a varying number of keys that represent jobs. A job can be anything from copying files around to generating the build version of an application or its API documentation. Consequently, jobs deploy certain keywords to trigger those actions, along with necessary configuration data like where to look for source classes, where to place outputs, where to find resources, and so forth. To foster re-use (and limit unnecessary typing), config files deploy three basic mechanisms: They can include other config files, and jobs can "extend" each other (This works a bit like inheritance between classes; the parent job's settings are merged into the current job, which can add new settings or override some of the parent's settings). The third tool are string macros that are expanded in other strings in the config.

For the curious who want to get their feet wet and their hands dirty, the generator2 config page provides a lot of further stuff to read and ponder. Feedback welcome.

This article is for the theoretically inclined among us :-).

When putting together a JavaScript application order matters. Since the browser
evaluates JavaScript code in the order it arrives, every code that is referenced
by other code has to come beforehand, in order for that reference to succeed.
This for example affects calls to other functions within the body of a certain
function, since these references are resolved at load time by the interpreter.

The same holds true for the prototype reference used for a "derived" class
(constructor) object. The "ancestor" function has to be loaded before you can
use it as the prototype for another function.

In qooxdoo, classes are declared as maps which are passed to a
class-constructing method, qx.Class.define(). This method creates the basic constructor object, sets the prototype and other prototype properties, and so forth. It is only when qx.Class.define is actually executed that all referenced objects in the class definition have to be in place, the most prominent being the "extend" member of the class which names its parent class.

qooxdoo's generator goes to some length to assure that classes are constructed in the right order. This is reflected in the script/<application>.js file which contains a list to the appropriate class files (in the "source" version), or the actual class code (in the "build" version). Obviously, classes that serve as base classes for others have to come earlier. But this is not all there is to it. Classes not only inherit from other classes, they also use them, through creating instances of them in their own code or calling out to static functions. Whenever code that does that is evaluated those other classes have to be in place.

You probably already know where this is going to, there is a risk of circular dependencies. A simple example might illustrate that. Most classes in qooxdoo derive from qx.core.Object, e.g. the Logger class. But qx.core.Object itself might want to start logging early when it is created, that is "use" a Logger instance. Another typical example for complications of this kind is the 'tr' function that needs a qx.locale.LocalizedString, which might not be present at the time you call 'tr'. A point in the class declaration where this might crop up is the 'defer' section, which contains code that is actually run after the class has been constructed, but might include references to classes that are not readily present in the interpreter.

On a general level what we are looking for is a partial order on the set of qooxdoo classes, the relations in question being "require" (the other class is a parent class) and "use" (the other class is used in the code). The question is: Is there a partial order for the qooxdoo classes under the combined relation "require/use" where a class A "comes before" a class B exactly when A is required by B and/or A is used by B. Only if there is such an order can qooxdoo classes be sequenced consistently.