qooxdoo comes with several different application templates or skeletons. Each is meant for a specific usage scenario and includes a different subset of the qooxdoo framework (see the architecture diagram for reference).

When creating a new application using create-application.py, the -t or --type parameter specifies the type of skeleton to be used, e.g.

qooxdoo-5.1-sdk/create-application.py--name=custom--type=mobile

The following skeletons are available (The application types are in fact all lower-case, but are capitalized in the following headings for better readability):

This is an alternative to working with the Website library directly, which is a single-file download containing all the qx.Website API. If you deploy the download you use its API in your own code in a way that suits you, e.g. by adding custom code in an HTML page that also loads the library.

The 'website' skeleton provides you with the same development model, with additional options. It contains a pre-built version of the Website library. You can just open the contained index.html file in a browser and see the default application running (If this is not the case and you just get an "Application needs generation..." message, just run generate.py on the shell). Then you start extending it, either in the index.html file directly or by creating other JavaScript files that use it, and include those in the HTML file.

Both approaches (download or skeleton) pretty much match up, with the skeleton giving you a little head start. In both cases you are using a static library file, and take care of organizing your application code yourself. Beyond that the 'website' skeleton provides you with some additional jobs:

build-min: You can re-create the library file (located in script/), by running the generate.py[build-min] job. This is interesting if you e.g. upgrade to a new qooxdoo SDK and want to make sure you are working against the latest code.

build: You can create a non-optimized version of the library, if you want to debug into its code. This is achieved by running the generate.pybuild job. Mind, though, that you then need to include q-5.1.js in your HTML code (rather than q-5.1.min.js which is the minified version).

test, test-source: You can write unit tests for your custom code, and generate a local version of the Portable Testrunner using generate.pytest or generate.pytest-source (The linked description of the Portable Testrunner refers partly to the ready-built download version, hence it says "no compile step"). In order to sensibly test your code, you should put it in its own .js file, rather than inline it in the index.html. This way, you can load it both in the application index.html as well as in test/index.html where the unit tests are applied.

api, api-data: These jobs re-create the qx.Website Apiviewer (or just the API data, respectively) in the skeleton. This is useful if you want to have the API documentation close-by.

For applications running in "browserless" or server-side environments such as node.js and Rhino. The skeleton follows the normal qooxdoo development model, so you have a source/ folder with classes and resources, and can create source and build versions of your app. It also supports other development jobs like "test", "api" or "lint". The special job "library" allows you to re-create the qx.Server library locally.

This skeleton depends on a generated Server library, located in script/. If this was not delivered with your SDK you can create it locally, by running generate.pylibrary. (If you intend to create multiple 'server' skeletons, you might want to change to ${QOOXDOO_PATH}/component/standalone/server and invoke generate.pybuild. This will generate the library for further 'server' skeletons).

The library will be used together with the application code to make up the final application. You need to generate the application first, e.g. by running generate.pysource. The generated source file is saved under source/script/<custom>.js, the build file (with generate.pybuild) under build/script/<custom>.js. Those files can then be executed.

After you have created the source or build version of a basic application, you can run it through either Node or Rhino. But as they have different loading primitives, Node allows you to run the app from a remote directory, while Rhino needs to run the application from the current working directory. So e.g. after creating the source version of an application foo, you can invoke it like this for Node: