qooxdoo

How to get information about libraries in qooxdoo?

I want to get info about libraries listed in compile.json (libraries section) during runtime. How could I do it? What sort of information I would like to get is meta information about themes used in libraries.

Solution

  • There's two things here: firstly meta data (which you would have to serve up to your client manually) and secondly, runtime information which is compiled in.

    Meta Data

    This data is used by the API viewer https://github.com/qooxdoo/qxl.apiviewer

    There's two sets of meta data - firstly, when you compile with qx compile, the compiler will output a db.json in the root of the target's output (eg ./compiled/source/db.json) - this contains information for each class, for every application, including dependency information.

    The snag here is that if you add an remove dependencies, there could be classes listed in db.json which are no longer used, and if you have several applications you will need to walk the dependency tree to find out which classes are used by which application.

    The second set of data is that every class is transpiled into the compiled/source/transpiled/ directory, and has a .js, .mpa, and .json file - so for qx.core.Object you will have ./compiled/source/transpiled/qx/core/Object.{js,map,json}

    The class' .json file contains loads of information about superclass, interfaces, mixins, members, and properties - and for each one, records the parsed JSDoc as well as where in the original source file it occurs.

    Runtime Information

    There is a global environment variable called qx.libraryInfoMap that lists all the information about all of the libraries which are compiled in - the contents comes from the library's Manifest.json

    There is also qx.$$libraries which is a global variable which gives URIs

    Safety

    None of the data above is considered documented and immune from changes in structure - technically it is internal data structures, but it's reasonably unlikely to change and using it is supported.

    Because of the impact on other peoples code as well as our internal tools such as the API viewer, we would try to not change the structure, but it is not guaranteed and a minor version bump could (potentially) make a change in the structure.