Qooxdoo - what's the easiest way to include a specific qx class into the API

Question

I'm trying to include qx.io.reques in my application but i can't seem to find the right way to do it!

I tried to configure the configure.json file and added "API_INCLUDE": ["qx.io.request*"] in let section and ran the file again but it didn't work.

Running ./configure.py source-all fixes it but makes it very slow to load the application because it's loading all the classes in the api, i need only the default classes along with qx.io.request.

I read the documentation in qooxdoo website but i couldn't understand all the different options and which one works for me.

i want to enable xhr requests in my application so that i can send ajax requests, is there an easy way to do that?

Answer 1

In case anyone else run through the same problem, i found two ways to do it:

---

1- Run the generate.py file using source-all flag, this would include all the available classes in the api.

./generate.py source-all

then run the generate.py file without flages, this will remove all unnecessary classes and leave the ones used by your application.

./generate.py

---

2- Edit the file configure.json and scroll to the "let": section and add the property "API_INCLUDE" and set it's value to whatever classes you want to include in your application like this:

"let":
{
    "API_INCLUDE"  :    ["qx.io.request.*", "qx.ui.toolbar.*"],
    "API_EXECLUDE" :   .....
}

then run the generate.py file with api flag:

./generate.py api

---

Answer 2

For one thing, you are trying to include a class into your application. In qooxdoo, you simply do that by using the class. So if you want to make an Ajax request, you simply write code in your application that uses one of qooxdoo's IO classes, e.g.

var req = new qx.io.request.Xhr("/some/path/file.ext");

and let the Generator include the Xhr class in your application.

This will happen with the next run of ./generate.py source or similar (there is no ./configure.py what you wrote). An exception is, as you wrote in your own answer, running the source-all job as it includes all known classes into the app, so the build will work whatever classes you are actually using. As for documentation, jobs are documented here.

So generally speaking, you will normally not need to make any configuration changes, in order to use a specific class from the framework, you just use it in your code. If for some reason a class is not included although you actually use it and have re-build the application, you can use the include config key to force the inclusion of this class. But this should be a rare exception.

The API_INCLUDE macro you mention only influences the generated API documentation which is entirely different from your application itself. (An application is usually not referred to as being an "API"). To see the difference just run ./generate.py source and open source/index.html, as opposed to running ./generate.py api and opening api/index.html. The first is your application, the second the API documentation for your application.